As part of the budget proposal process, it is often a good idea for proposal creators to get feedback on their idea prior to spending BLTG on submitting a proposal to the network. In order to facilitate this need, we have set up this forum as a place for proposal creators to pitch their draft ideas, get feedback, and make any adjustments (if needed).

Below are some guidelines that will help standardize this process, avoid the need for a lot of unnecessary clarification questions, and hopefully result in more detailed and well thought out (and easier to read) pre-proposals.

Have a header section to provide at-a-glance details
Include a code block at the start of the post with the following information:

Title: A "human readable" title for your proposal, can include spaces.

Name: A sanitized proposal name, no spaces or special characters. This is what would be used during the submission to the network (Please don't re-use proposal names).

Term: The number of cycles your proposal would be for.

Cycle Amnt: The number of BLTG you are seeking to get per-cycle.

Total Amnt: The total number of BLTG you are seeking (cycle amnt * term).

Author: Name/pseudonym of the person(s) who wrote the pre-proposal.

Receiver: Name/pseudonym of the person who will be in control of the BLTG address receiving budget funds.

Address: BLTG Address to be paid out by the budget (optional for pre-proposals).

Created: Date of posting/revising (optional, but good to have).

Status: Draft, Pre-Proposed, In Review, Awaiting Feedback (optional).

Include a brief overview
Having a 1-2 paragraph overview (abstract, synopsis, summary) of your idea gives others the opportunity to familiarize themselves with your idea on a higher level BEFORE being subject to the finer details, explanations, price/cost breakdowns, etc.

Think of this as a sort of "TLDR" (though everyone really should be reading the entire proposal's text).

Define/Describe your commitments, standards, etc up front
It is good practice to define any kind of commitments you are intending to make up front, before you go into the details of your proposal. These definitions are somewhat loose, and can change from proposal to proposal.

The important thing to remember here is that this is the place to say how you will be operating, whatever that may or may not entail.

Provide explicit details
After all of the above is done, it is now finally time to detail your proposal. This is where you explain in painfully blunt or explicit detail exactly how you look to achieve your goals should your proposal pass and get funded. This is the place to give a full accounting of where requested funds will be going, as well as give justification for such funds. Keep in mind that the BLTG budget operates on BLTG and NOT on USD/EUR/KRW.

When you submit a proposal, you and you alone are responsible for covering any market changes over the course of your proposal's term length. This is also a great opportunity to consider other pre-existing proposals and how yours may or may not impact them, as well as how their existence may or may not impact your own proposal.

Be explicit in your funds distribution breakdowns so as to avoid a situation where someone is unclear as to where funds may or may not be going. For example, proposal creators are certainly welcome to request reimbursement of the 50 BLTG submission fee, just include that in the cost breakdown if such reimbursement is requested. Likewise, if you wish to set aside some requested funds for any unforeseen circumstances, such a case should also be detailed.

Avoid External Links
The entirety of the proposal should be included within the text of your forum post. Avoid linking to a Google Doc or any other website to detail your proposal. Services like Google Docs are perfectly fine when used as a staging area for a proposal, nobody likes following external links...especially to a service that is known for tracking user data/behavior.

(Pre-)Proposals should be self-contained, meaning that the complete proposal should be available in your post. Images can be attached to forum posts if needed, as well as tables using the visual editor here on the forum. If you must reference an external source, consider a GitHub Gist (as a supplementary/backup link).

Note: This pertains to (Pre-)Proposal details only. If your proposal involves a 3rd party entity/project, you are certainly welcome (and encouraged) to provide links to any 3rd party websites for general information purposes. An example would be if a proposal was proposing an alliance or integration with a non-BLTG entity, you would generally want to provide a link to that entities website.

Promote your Pre-Proposal
It is the responsibility of all proposal creators to make the community aware of their pre-proposals. Never expect others to see your submissions on their own. Self-promotion and direct engagement with the community is key to getting feedback and/or traction for your proposal.

While getting feedback here on the forum is the preferred method (for historical reasons), it is perfectly acceptable to consider feedback from any outlet, as long as you as a proposal creator pay attention to other outlets.

Avoid long-running proposals
Changing conditions over expanded periods of time may lead to a situation where the original cycle amount is no longer suitable, or that fundamental changes in the operation of a proposal's work need to be made. Limiting the total number of term cycles to no more than 3 ensures that any such changes or re-evaluations can be met in a timely manner, whilst also avoiding situations where a proposal that is stale or otherwise not meeting the passing threshold from needlessly lingering on the network.

Budget & Governance