BlackHat Budget Pre-Proposal Submission Guidelines

Post Reply
User avatar
Site Admin
Posts: 21
Joined: Tue Apr 13, 2021 7:40 am

BlackHat Budget Pre-Proposal Submission Guidelines

Post by AlexBlackHat »

Original post by fuzzbawls

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 BLKC 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 Amount: The number of BLKC you are seeking to get per-cycle.
  • Total Amount: The total number of BLKC you are seeking (cycle amount * 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 BlackHat address receiving budget funds.
  • Address: BlackHat 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).
Standard BBCode works here, just put [ code ] before your first header line, and [ /code ] after your last header line. The result will look like the image below when viewed by others or with the "Preview" function prior to submitting the post:

Code: Select all

Title: BlackHat Dev Funding (Sep-Nov 2021)
Name: BlackHat-Dev-SepNov2021
Term: 3 Cycles
Cycle Amount: 8000 BLKC
Total Amount: 24000 BLKC
Author: Alex Black
Receiver: Alex Black
Address: TBA
Created: 2021-08-15
Status: Pre-Proposal
Also, to get a feedback for your pre-proposal you are able to create Poll within your proposal thread.

The forum thread for pre-proposal creation is Pre-Proposal Discussions

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 BlackHat budget operates on BLKC 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 BLKC 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-BlackHat 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.
Post Reply