This page will serve to document all created and discussed policies about the project, including the live server. These can include policies developers have to follow, as well as policies staff have about the project and the game that must be maintained, including by the owners of the project.

The offered XP rates are permanently locked to 1.0, 2.5 and 5.0. Under no circumstances are we to change, add, subtract, replace, substitute or modify these options. These are 100% completely final. The consequences of these XP rates are to be dealt with in their own right, and not be used as an excuse to add, substitute or remove any of the present options.

Excluding the removal of 10x and 20x, under no circumstance should a player's xp rate be modified or tampered with beyond the programmed-in limitations.

Rollbacks are only to be accepted in the context of a punishment for some form of bug exploitation, or to remedy an issue produced by a bug. Authentic bugs do not count for either of these.

Username changes are allowed provided that the username a player wishes to change to is currently unused. If a player desires a username change, they should submit a request in the #live-server-help channel of our Discord in the following format: <dtable>

</dtable> Where proof of account ownership can include a timestamped screenshot of that user logged into the game.

We here at the 2009scape team don't believe it's fair for players to horde up a bunch of unique usernames for themselves and never use them. Because of this, a user can request that we check on and/or free up a taken username. A username will be freed provided that it meets the following criteria:

• Total level below 1k
• Has not logged in for at least 6 months

The request to investigate and potentially free a taken username should be posted in the #live-server-help channel of our Discord.

• If you can still log in: Use ::resetpassword ingame to change your password.
• If you can NOT log in: You need to make a request in the #live-server-help channel of our Discord. The form for the request is as follows:

<dtable>

</dtable>

Where proof of account ownership can be one or more of:

• Name of the computer the account was registered on
• Date the account was created on
• IP Address the account was created from (feel free to DM Ceikry directly if you wish to not reveal this)

If you can not provide any of these, we can not reset your password.

Developers are expected to make all changes in their own forks/branches and create a pull request to the main repository with their contributions. If you do not know what these are or how to do them, look at the gitlab documentation.

Developers are expected to have their forks/branches fully up to date before submitting pull requests in order to avoid merge conflicts.

New bot scripts must undergo a thorough review before being allowed into the game. The criteria for an acceptable botscript are as follows:

• The script should not enable the automated farming of any high level items, materials or resources.
• The script should be designed to automate some boring task or grind
• The script should not offer active advantages to other players other than offering for sale low level resources on the grand exchange.

Generally, custom content should be avoided, but we reserve the right to consider custom content provided it matches the following criteria:

• The custom content does not obsolete any existing items or content, and does not trivialize any ingame content.
• The custom content is well-balanced (not overpowered)
• The custom content fits the theme and lore of Runescape/2009scape
• The custom content enables more horizontal playstyle customization

Some people may be confused or not understand what the point of an RFC is. Well, since 2009scape is an Open Source project, it is community-driven. What this means when it comes to making massive changes or adding inauthentic and/or anachronistic features is that community feedback and engagement is vital to the process. The whole point is to carefully refine ideas BEFORE they ever get implemented. Below is a general overview of the process:

The RFC stage is the initial proposal, and refinement of the initial proposal. An initial suggestion or proposal is put out, and then discussion is opened up for the community to criticize, share concerns, etc. Provided that there are valid criticisms and concerns, adjustments to the proposal may be made, and often are. This cycle will repeat until it seems like a good compromise has been reached amongst the community, and it is then moved on to the polling stage as a final suggestion. All feedback is ABSOLUTELY critical at this stage. If something fails to garner enough feedback or engagement at this stage after a sufficient amount of time, usually 24-48h, then it will be closed and left to be reconsidered at a future date. That is to say: RFCs that do not receive feedback or engagement CAN NOT be allowed to proceed further into a poll or implementation, due to the exact nature of this process.

After the initial proposal/RFC has gone through one or more cycles of refinement, a verbatim final-proposal is opened as a poll. The community can then directly vote on whether or not the verbatim final proposal should be implemented. Should something fail the poll at this stage, there is room to reopen the RFC for further discussion. Should a proposal pass the poll at this stage, it is then guaranteed to be implemented at some point in the future. This could be immediately, or three months from now, or a year from now, etc. It heavily depends on the content of the proposal and the status of the community.

Assuming the poll has passed and the final proposal has been accepted, it is then ready to be implemented. This can be done by a core developer or a volunteer, and can be done at any time. Once something has reached this stage it is fully approved to be in the game, so it does not matter who gets it in, as long as it gets in at some point.