We are happy to open up the next RFP. This RFP requires documentation instead of code but can still have a major impact on Decred. RFP0004 - Refactor and Update Wiki Documentation Note: This RFP is open to you. You are asked to submit proposals if you are competent in this area and the money will go to you if your application is successful upon completion of the work proposed. Please send all proposals to: rfp2016 <at> decred.org Closing Date: All proposals must be submitted by 06:00 PM UTC March 8th, 2016. Description The Decred Wiki is in need of refactoring and updating to make it easier for interested outsiders and novice users to learn about Decred, setup a wallet, perform other basic actions and to understand how the various network parameters affect their user experience. Requirements Familiarity with setting up dcrd, dcrwallet, web wallet, and stake mining on Linux and Windows Ability to write clearly and simply in English A decent understanding of the details of how Decred works as a cryptocurrency Experience writing documentation is optional Scope In order for Decred to gain more users and wider acceptance, it must be made more tangible to outsiders and novice users by having simpler explanations of how Decred works and why they should use it. The Bitcoin wiki at bitcoin.it is a good example of the sort of simplified explanations that are needed for Decred. This is particularly important for Decred's new hybridized Proof-of-work/Proof-of-Stake system. A rewrite or substantial editing is required for the landing page and the introduction page. Setting up a Decred wallet seems to be a difficult process for some users and there are several common misunderstandings that arise in that context. Guides must be created for setting up the web wallet and dcrwallet on Linux and Windows that are simple, minimal, easy to follow and include screenshots. Based on posts on the forum, it is clear that people have trouble understanding how wallet seeds work and how they need to be handled from a backup and security perspective, so there needs to be content specifically addressing these issues. Some parts of dcrwallet and the web wallet do not work as expected or planned, and users must be warned about these limitations. The documentation for setting up stake mining needs to be simplified and made clearer. The solo stake mining section requires simplification and updating so that relatively novice users can both understand the requirements of such a setup and get it working without event. A section on stake mining using a stake pool needs to be added. A single page explaining the various network parameters of Decred is needed. These parameters are encoded in the dcrd source code and include things like block times, the subsidy change interval, retarget intervals for PoW and PoS, maturity times for tickets and votes and fee-related limits. Questions about these parameters come up very regularly, so this needs to be linked from the main page in a prominent place. Estimated Work 1 week FTE or greater (1 FTE = 40 hrs/week). Proposal Proposals should include: Estimated completion time Any proposed additions to the scope described above, along with a short explanation of why the scope should be changed. Payment required Milestones Partial payments shall be made at the following milestones: Completion of the wallet documentation updates Completion of the stake mining documentation updates Completion of the network parameter and introductory explanation documentation Modification of these proposed milestones is acceptable, and must be accompanied by sound reasoning in a proposal. Under no circumstances shall payments be made in advance of work being completed.
I am in i will complete it in a week and for the minimum payment that will be offered by you for one week FTE.
Hrmmm, my brother may have started doing something like this, actually. I'll ask him when I get a chance later. I know he was writing SOME kinda introductory thing for Decred, whether it's instructional/technical enough, I'm not sure.
Does translating the documentary from english to german also count for this proposal or will this be included in a different one ?
In order to not have the scope of this RFP creep, we will not include translations in this RFP. We need to get the English one into good shape before it makes sense to translate it to other languages. We will make additional RFPs for the translations after the English one is complete.
@h3rtl31n This RFP is for working on the documentation in English, not for translating things (since we would need better docs in the first place before translating them would make much sense.
This is indeed a great RFP. Making adoption available for Everyone is a key priority in my opinion. I would love to do this, but I'm afraid I'm too much of a cryptocurrency newbie myself. Because of this, and because of my excellent English language skills, I would be a great proofreader / editor / reviewer. @jcv Would it be within the scope of RFP-4 if I submit a proposal for these type of tasks?
@Noah while I can't rule out a clean type RFP later on I think this one needs to focus on actually generating the documentation (since the type of thing you are suggesting, while very important, requires actual documentation that we currently lack).
I can write about solo stake mining, as I set that up myself and have had my setup running nonstop since block 4096. My English is clear, and I know somebody who teaches English as a second language who could help ensure that what I write is easily understandable to non-native speakers. The only thing I can't do is write pretty HTML (I can embed pictures and format text, but that is about it). Will I need to be proficient in HTML, or can I just submit the documentation itself?
@blackdragon Writing documentation on a wiki does not require significant html skill. It requires getting the wiki formatting correct but that is a very small subset of html.
That is up to the user who submits the proposal, since different people work to different schedules. As long as it's within reason, different time frames won't affect the viability of the proposal.
Great, I have some free time comming up and was wondering it was too far away, I'll be sending my proposal today.
Decided to throw in a proposal for this one. I'm only covering milestones 1 and 2. I assume that this is ok? I'm also perfectly available to pickup just one of the milestones for which I applied. Would be great to see the RFPs getting multiple collaborators involved, each taking on a milestone or so. Future translations might be the ideal fit for that, once the main/English content covers all the important topics and has matured a bit. Cheers!
I am still not sure how the payment works, but I am OK with learning by doing. First, I do consulting for a living, and one key to that is a LOT of documentation. Some of my gigs have been pure discovery and documentation. I also did the documentation for the SmallWall project. http://www.smallwall.org/documentation.html I work most often in Wiki, but he SmallWall stuff is static pages for security. (Nothing Internet facing is dynamic.) As to scope and time, the scope is a bit unspecific, but that is common. I am thinking instructions at the level of a user that can find and install printer drivers without help. (That is how I wrote the SmallWall documentation) The time is different. The discovery is the open part, but I am looking into a lot of this personally anyway, so I am not counting it heavily. I am thinking it will take 20-30 billable hours, over about a 3 week period with feedback. Does this count as a proposal, or do I need to send a document and scope to someone?
Nice one @Lee Sharp . I figure that adding a quote (in USD) per milestone, and sending it via e-mail to rfp2016 [at] decred.org , is the official way to go. I suppose it might also be wise to get some input from the devs on it anyhow. Good background there btw!
Thank you to everyone who submitted proposals. RFP-4 received an immense amount of interest and a record number of proposals. It is clear that there will be a number of documentation-related RFPs in the future as well, as it is a continuous process that will expand and refine over time. A number of factors are taken into consideration when deciding which proposal best suits the task. These are (in no particular order and always taken in combination): (1) the experience of the applicant, (2) the cost to the development subsidy, (3) the comprehensiveness of the proposal, and (4) the timeline of the submission. Whilst this RFP received many applications that excelled in all of the aforementioned factors, completion of the task at hand becomes difficult when involving too many parties. However, this RFP saw proposals submitted by parties who offered to work in a peer review fashion, which is attractive for developing documentation. As such and to get RFP-4 started, @Shadowlance, @David and @zkott will all work on the documentation to produce the deliverables for this RFP. Consultation is currently taking places with and between them to develop the best way to integrate their respective proposals. As always, please do not feel discouraged from putting forward proposals for future RFPs, as the RFP process is continuous and iterative. Every round is a blank slate for you and your contributions are encouraged and valued.