Skip to content
This repository has been archived by the owner on Apr 22, 2021. It is now read-only.

Latest commit

 

History

History
108 lines (73 loc) · 5.56 KB

proposal-selection.md

File metadata and controls

108 lines (73 loc) · 5.56 KB
Raw
layout
default

Proposal selection process

This process is used when selecting major initiatives to incorporate into the baseline of The Good Docs Project. In particular, it is used when deciding upon proposals to sponsor.

Version: 1.0

Last updated: August 2020

When do we use this process?

This process is initiated periodically and typically depends upon:

  • Timing of current build cycles.
  • Sufficient bandwidth available within the community.
  • Budget availability.

Timing will typically align with the Season of Docs schedule.

Call for proposals

On initiation of this process, a call for proposals will be sent to public forums, which will at a minimum include our announce email list. The announcement will include references to:

  • Expectations for proposals.
  • Prioritization guidelines.
  • Eligibility.
  • Associated timelines.
  • Budget availability (if applicable).
  • How to submit the proposal.

Eligibility

  • You should be actively involved in The Good Docs Project or a related community. (Note, involvement in our community is open to all.)
  • You will need to have won the trust of this community in order to have them back your proposal.
  • You will need a mentor before you get an application approved.
  • You should fit with the eligibility criteria of Season of Docs:
    • You must be at least 18 years of age when you register.
    • You must be eligible to work in the country you will reside in during the program.
    • You must reside in a country that is not currently embargoed by the United States. See the program rules and the Sanctions Programs and Country Information from the US Treasury.
  • We support diversity and encourage applications and involvement from under-represented communities.

Implementation process

A variant on the following process should be considered for major initiatives.

Test the waters:

  • Float an idea in our community forums.
  • Look for feedback, interest and engagement.
  • If you attract significant community interest and support, and the required effort is more than is likely to be addressed by volunteers, develop a proposal for sponsored work.

Prepare proposal:

  • Develop a proposal in conjunction with the community. Make sure it addresses our project priorities.
  • Find a trusted member of our community who is willing to mentor you.
  • Share proposal.

Review proposals:

  • Community review and discuss proposals.
  • Community decides if the proposal is worth backing, and locks in if it is.

Implementation phase:

  • The worker works according to the proposed plan.
  • The worker checks in weekly with mentors and other collaborators.
  • Worker provides a weekly status. This can be brief, just a few lines.

Wrap up:

  • Write a report, hand over documents and present to the community.
  • Send an announcement to the main mailing and slack #announcements channel.
  • Arrange for a tweet and/or blog post to be created announcing the project completion, linking to the finished work.

Payment process

  • Where applicable, guidance on budget will typically be based on the stipend amounts used by Season of Docs (20-30 hours per week x 3 months, or equivalent effort spread over 6 months). This will be referenced from the Request for Proposal.
  • Payment milestones will typically be every 3 months.
  • Payments should be correlated to milestones as github tasks.
  • When a milestone is reached:
    • The implementor should comment on the milestone task, asking the mentor for review.
    • The implementor should raise an invoice with our Open Collective account.
    • The mentor should review the milestone, and either approve it (by closing the issue) or reject it (by providing feedback on what is still needed to reach the milestone).
    • If the milestone is approved, the mentor should raise a motion with the PSC recommending that the payment be approved.
    • Once approved, a treasurer (not the mentor) should approve the Open Collective invoice, and the mentor updates the decision log with payment approval.

Project Adjustments

  • Project scope may be adjusted by mutual agreement between the mentor and proposer.
  • Scope changes must be approved by the mentor and PSC decision process.
  • All scope changes must be documented in writing.

Project completion

  • Projects are not considered complete until all pull requests associated with the scope of work are merged and any final project report (if part of the original project proposal) has been submitted.

Transparency

  • All financial transactions will be publicly visible in our Open Collective budget, including who the money is provided to, how much was spent, and who approved the spend.

Conflict resolution

  • Proposers and implementers may escalate unresolved issues to the PSC (such as lack of review, lack of communication, or discrimination).
  • The PSC shall endeavour to address concerns raised and arbitrate fairly.
  • The decisions of the PSC are final.