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:
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:
The request to investigate and potentially free a taken username should be posted in the #live-server-help channel of our Discord.
Where proof of account ownership can be one or more of:
If you can not provide any of these, we can not reset your password.
We can reset your account to a clean slate if you so desire. You will, of course, have to provide some proof of account ownership. Submit the below form in the live server help channel in our Discord:
[ACCOUNT RESET REQUEST]
Where proof of account ownership can be one or more of:
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:
When an issue is created on our Gitlab page's issue tracker, a staff member will assign a certain number of credits they believe it to be worth. Should the issue be fixed by a contributor and fully merged into the codebase, the person who reported the issue will receive a credit, and the person who fixed the issue will receive the full amount of credits listed for the issue. Only in very rare circumstances will a contribution that doesn't address a listed issue result in a credit reward, as a staff member did not have adequate time to assign that issue a credit value.
Should an issue be fixed by the same person who reported it, they will receive the listed credit amount plus the bonus credit for the initial report. This is just to keep things simple.
The main thing a player or contributor should take away from this is that reporting bugs the proper way is very important, and focusing on already-reported bugs when decided what to fix is equally important.
Contributions for new content, like adding a new quest or minigame, or adding some other piece of content that was plainly missing/never implemented, will function differently and will receive a credit reward based on a careful evaluation of the time and effort as well as the quality of the contribution. A small and very well written quest might have a very worthwhile reward, while a large and poorly written quest might give substantially less credits than one might expect. Quality is better than quantity here.
Generally, custom content should be avoided, but we reserve the right to consider custom content provided it matches the following criteria:
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 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.