### Proposal Guidelines

These are some loose guidelines for creating proposals. They are intended to set out a clearer path for users to follow in order to maximize the likelihood of success of their proposals and although there is no strict requirement to follow them (anyone with enough tokens can submit a proposal, and the council can vote however it likes) they are hopefully sensible and readily understandable for all users.

1. Proposals should clearly address who the intended recipient is. There are two options for this:

	* Addressing `The Council`. The Council can do certain things within the framework of the testnet, but The Council cannot directly influence how Jsgenesis acts or how Jsgenesis allocates funds. As an example, if the fiat pool is replenished at a certain amount per week, a proposal cannot change this. What a proposal can change is worker rewards, budgets within the testnet, projects that can maybe be funded by the council if they approve of using the council mint or adjusting Working Group budgets.

	* Addressing Jsgenesis. Jsgenesis is the company developing Joystream. They are mostly focused on software development and have limited involvement within the community. Jsgenesis controls certain aspects of the testnet (such as the overall budgets). Someone could address Jsgenesis in a proposal and request changes, but it is at the discretion of Jsgenesis to do any changes. Please note that Jsgenesis is usually extremely busy on a constant basis with numerous aspects of software development of the platform, so even an `approved proposal` cannot guarantee any response, nor the speed of a response)

2. If a proposal asks for funding, it should clarify where the funding is expected to come from. This could include a number of options, such as the council's mint (done via `spending proposals`) or from Working Group payments (these are managed by Working Group leads).

3. Any proposal that requests funding, or seeks approval for funding should ideally include a clear series of milestones as well as information on who the payee would be, relevant timeframes, any appropriate deadlines and as much detail as possible.

4. Proposals of substantial complexity (involving deadlines, milestones and fine details) should ideally be presented as a `pre-proposal discussion` in the appropriate forum subcategory: (https://testnet.joystream.org/#/forum/categories/49).

	- This discussion will help people to give feedback on your plans before making a proposal and can possibly make it more likely that your proposal will succeed when it is presented as a proposal.

	- These also help to build the platform's knowledge and help future users to build better proposals.

	- Submitting complex proposals without any prior discussion may limit your chances of success, simply because when you submit the proposal it is the first time anyone has had a chance to think of it and some of the details presented may be different to what council member's are prepared to approve of via voting.

5. All `spending proposals` are requests to draw funds from the Council Mint. In some case, most notably for "official bounties", Jsgenesis may choose to reimburse (meaning add an equivalent amount of Fiat) the funds, if they approve of the work. When making a `spending proposal`, you should make the following clear:

	- Why you are requesting funding (If it is for a bounty, which bounty is it for?)

        - Links to work that has been completed (or if you are seeking funding for work you want to do, this should be stated clearly)

	- The USD equivalent you are requesting

	- To whom the funds are going

	- Whether this is intended to be reimbrused or not

	- If you have a role on the platform, you should explain what it is