JIP1 + basic setup

.gitignore

@@ -0,0 +1 @@
+.DS_Store

README.md

@@ -1,2 +1,24 @@
-# jip
-Joystream Improvement Proposal (JIP) Repo
+# Joystream Improvement Proposals (JIPs)
+
+>  A social process for improving Joystream.
+
+A process for how to propose and enact new standards for the Joystream Network and surrounding ecosystem, with an emphasis on transparency, verifiability, formality and clarity, by using the  governance, identity and publishing capabilities of the Joystream blockchain.
+
+Please note that this repository is for documenting standards and not for help implementing them. 
+
+For specific questions and concerns regarding JIPs, it's best to comment on the relevant discussion thread of the JIP denoted by the `forum-thread` header in the JIP's preamble.
+
+If you would like to become an JIP Editor, stay tuned.
+
+## Guides
+
+Tailored guides have been prepared for the different stakeholder roles, in order to give a focused distillation of how they should proceed at various stages of the process
+
+- [authors and owners](author_owner_guide.md)
+- [editors](editor_guide.md)
+- [domain authorities](domain_authority_guide.md)
+- [council members](council_member_guide.md)
+
+## Validation and Automerging
+
+`TODO`

guides/author_owner_guide.md

@@ -0,0 +1,26 @@
+# JIP Author & Owner Guide
+
+## Background
+
+This guide attempts to help prospective JIP authors and owners understand the process. It is a distillation of the [JIP standard](../jip-1/jip.md) from the authors point of view. It may also be useful to read the guides offered to [council members](council_member_guide.md), [domain authorities](domain_authority_guide.md) and [editors](editor_guide.md)
+
+## Guide
+
+1. Ask yourself the question "Is this a problem that involves how people coordinate?", if it is not, then it is likely that this should not be  a JIP. For example, if you believe there is an issue in the on-chain business logic, or how infrastructure nodes interact, or the message format in certain on-chain metadata standards that apps use to interoperate or how a certain kind of on-chain proposal is deliberated upon, then a JIP may indeed by appropriate.
+2. Review the set of JIPs already in the repository. Are any of them relevant to the problem you are wanting to address, potentially being alternative or conflicting solutions. There may also be JIPs you may want to rely upon to be more aligned with already known standards.
+3. Review the JIP idea stage forum category to find any idea stage JIPs, for the same purpose. If you find any any matches on either this or the repository, revise your understanding of the problem, and possibly the idea you have for a new standard.
+4. Create a new thread on the forum in the JIP idea category, with suitable title, and a very brief statement of what problem you are interested in addressing, and what approach you are contemplating as a new standard to address it.
+5. Contact one of the JIP editors using contact information found as part of their membership, and make them aware of the new idea. They, and others will make you aware of who you should speak to about this idea to get more feedback and possible help.
+6. When you are satisfied that you have received a sufficient amount of feedback, and you still believe there is a case and positive prospect for adoption of a new standard, familiarize yourself with the JIP process and document template, and notify your JIP editor contact that you intend to create a JIP, and try to be clear about timeline, as well as who you believe will be interested in the proposal. If you intend to create a Council proposal, you are well served to develop a strong support and understanding of what you are trying to do before investing any more time, as you will need buy-in to get it adopted within a specific timeline, and failure to do so results in a conclusive rejection, while community proposals are never conclusively rejected. If people have not expressed a clear attitude, one way or the other, try to develop an understanding of what exactly they would like to see to consider it worth while to review more carefully, or de-risking some specific part of the proposal. For example, would people want to see a reference implementation, test cases, an economic model or simulation work, more data collection, etc.
+7. Prepare your JIP document, and run the tooling script to make sure that at least some subset of the official document constraints which have automated verifiability, are satisfied. As a general rule, editors will be very time constrained, and hence being able to do your part of the collaboration effectively will likely incline them to give you more of their time.
+8. Open a pull request with your JIP draft, and make sure to not set the JIP number, and notify your editor.
+9. Collaborate with your editor to change the document, as required. The editor will only ever make changes to the document preamble, not the body, that will be your task. Be respectful, efficient and most of all transparent about when you expect to be able to make progress. This allows the editor to allocate review time, and time wasted on missed deliverables is time that could have been used on other JIPs.
+10. When you editor is satisfies that the document is in an acceptable form for the `Draft` stage, they will open a signal proposal. This is not something you can do, and doing so will result in automatic rejection of the proposal. Be aware that while editors are gatekeepers selected by the council, meant to protect the integrity of the process and the bandwidth of the council, they are not supposed to do technical evaluation of the merits of your standard. They are merely there to help you follow the process and get information and support by connecting to the right people. The goal is for editor and authors to really never disagree on anything that would prevent a proposal from advancing, but in the off chance that this occurs, the only alternative is to speak to other editors, and in the last instance appeal to the council, to which the editor is directly accountable. Finally, for the proposal to pass, make sure that you and all other authors make an on-chain message, using the memberships listed in the document, on the proposal discussion thread to confirm your authorship. Make sure to do this promptly, as the proposal may fail if it is created at the end of a council period, and the council cannot pass it without your confirmations.
+11. When the on-chain proposal is executed, the proposal is in the `Review` stage, and the forum thread for discussing the proposal will be created. The editor will update the preamble of the JIP document.
+12. In the `Review` stage, you must offer timely replies to all well specified questions and remarks posted in the proposal discussion thread, and if multiple owners exist, they should coordinate amongst each other to do so effectively. Take questions and criticisms as opportunities to refine the substance and presentation of the standard itself, and to gain new supporters, rather than as personal criticism. Even hostile or adversarial correspondents could easily help you achieve these ends, and rely on forum moderators and the editor to police the conversation. The goal is to learn as much as possible about what you do no know, both technically and socially - in terms of the objectives and constraints of people who you would like to adopt this standard. For community proposals, you must consider you are offering a standard that itself needs to perpetually evolve, hence becoming a `Living` proposal, rather than a fixed `Final` proposal. The vast majority of community proposals should end up in the latter category. Ultimately, whatever you decide, the editor is the gatekeeper on this final decision. For council proposals, the single most important thing you can do is to speak actively with the domain authorities who are going to provide their opinion on whether the proposal should be enacted by the council. Their opinion does not bind the council, but is likely very authoritative.
+13. Whenever you make a change which is merged, remember that it should be reflected in the changelog, and also be posted by you to the discussion thread. To make sure you don't waste people's bandwidth, try to batch related changes, rather than making many small changes in sequence.
+14. If you find that you no longer wish or are able to continue pushing forward a proposal, you can try to find some other person to take over as owner, if none of the authors would be left. Such an ownership change requires that a proposal is opened to this effect, and that all current owners must agree. Contact the editor first if you wish to do such a change. If you cannot find a replacement, the only other option is then to let it end up in the `Stagnant` state. If you no longer believe the proposal should be adopted at all, you should withdraw it. Again, the editor can help you with this, and all owners must agree.
+
+## FAQ
+
+`TODO after more user input`

guides/council_member_guide.md

@@ -0,0 +1,19 @@
+# JIP Council Member Guide
+
+## Background
+
+This guide attempts to help prospective and actual council members understand the JIP process. It is a distillation of the [JIP standard](../jip-1/jip.md) from their point of view. It may also be useful to read the guides offered to [authors and owners](author_owner_guide.md), [domain authorities](domain_authority_guide.md) and [editors](editor_guide.md)
+
+## Guide
+
+The council has three responsibilities in the JIP process.
+
+1. Manage the overall integrity of the process through the JIP process parameter update proposal, where they signal key root of trust indicators and actors for the process. They must also possibly fund the involvement of key actors who must devote time and resources to the process, such as domain authorities and editors.
+2. Sign off on key stage transitions in the life-cycle of proposals. They should largely be verifying that the editors and authorities have followed the steps involved in the proposal for that stage transition, and that other appropriate third parties have signed off if required, such as owners or domain authorities.
+3. Enacting council proposals. This is their most important role, as enacting certain change has implications for how the networks operates in a way that may not be backwards compatible and which others cannot opt out of. Evaluating such enactments must be done informed by the judgement of domain authorities, but not bound by them. Ultimately the council is solving for whatever strategic objectives currently are important for the DAO, hence enacting a council proposal is ultimately a decision which takes into account a broad range of considerations.
+
+NB: this Guide probably needs to be expanded in the future, this is it for now, due to time constraints.
+
+## FAQ
+
+`TODO after more user input`

guides/domain_authority_guide.md

@@ -0,0 +1,13 @@
+# JIP Domain Authority Guide
+
+## Background
+
+This guide attempts to help prospective and actual JIP domain authorities understand the process. It is a distillation of the [JIP standard](../jip-1/jip.md) from their point of view. It may also be useful to read the guides offered to [council members](council_member_guide.md), [authors and owners](author_owner_guide.md) and [editors](editor_guide.md)
+
+## Guide
+
+`TODO`
+
+## FAQ
+
+`TODO after more user input`

guides/editor_guide.md

@@ -0,0 +1,24 @@
+# JIP Editor Guide
+
+## Background
+
+This guide attempts to help prospective and actual JIP editors understand the process. It is a distillation of the [JIP standard](../jip-1/jip.md) from their point of view. It may also be useful to read the guides offered to [council members](council_member_guide.md), [domain authorities](domain_authority_guide.md) and [editors](editor_guide.md)
+
+## Who are you as the editor?
+
+The most important high level guiding principle any effective editor must keep in mind is to understand their role properly. The role of the editor is as part cheerleader part umpire, trying to make good faith JIP authors and owners as successful as they can be in developing, promulgating and gaining adoption for their standards. This means helping them make themselves properly understood, getting robust feedback and following the rules of the game.
+
+## Who does what?
+
+The JIP standard does not try to make detailed recommendations about how editors coordinate amongst each other, but it is advisable that editors are proactive in autonomously finding their own means of making sure everyone is on the same page about who is responsible for what proposal. This will help avoid misunderstandings that risk leaving other stakeholders frustrated and disappointed.
+
+## Guide
+
+1. A good place to keep an eye on is the pre review JIP discussion category, as newcomers post JIPs at the idea stage. While the JIP process does not describe anything very specific when it comes to how exactly editors communicate with each other or with authors, however taking a proactive approach and being available is generally advisable. Importantly, keep up to date and accurate contact information on your membership which allows new authors to contact you directly.
+2. When a JIP enters `Draft` stage, and both you, your peer editors and the author should have aligned expectations around your role w.r.t that proposal. Your primary role at this stage is to make sure the document complies with the constraints of the process, and in particular that the domains listed as part of the proposal are appropriate for that proposal, if it is a council proposal. For council proposals its very important to give the owners an early indication about whether the standard is likely to pass or not, to conserve effort, and looping in the right domain authorities promptly is advisable to this end.
+3. The most important milestone in the life of any proposal is when it formally enters the `Review` stage, as this is when the public conversation can properly begin, and there is a fully specified proposal at hand. From this point on, merge owner revisions, and make sure they announce each merged change to the discussion thread, and also update the changelog on each merge. They should not edit the header preamble from this stage on, and you as the editor should only edit the this part. You must decide, in collaboration with the owners, whether this is a long lived standard that will need to be augmented indefinitely, or whether it should stop being edited after an initial review process. The former should be a proposal that ends up in the `Living` stage, while the latter progresses either for enactment or to `Final` stage, depending on whether it is a council or community proposal, respectively.
+4. Any stage transition, or change in ownership, must be published to the discussion thread as well, in a standard format, and it must be logged to the `proposals` header as well.
+
+## FAQ
+
+`TODO after more user input`