Thanks everyone for the feedback. I think I got everyone's thoughts integrated into this updated version.
I'm posting for another round of reviews. I think we're pretty close now, so if there's no further changes suggested I'll put it up for a vote maybe next week.
Bryce
Changes: * Added subheadings * Added Exception section clarifying board powers * Jobs expire after 30 months * Gave original proposer power to modify or terminate projects * Defined the Reviewer role * Added example Delivery and Acceptance Criteria as an appendix
Inkscape Funded Development Model ---------------------------------
1. Project Proposals ===================== We maintain a listing of proposed projects. Anything can be proposed, including feature development, bug triaging, documentation, administration, etc. It must have a defined deliverable and acceptance criteria identified, and a time limit for how long the work should take. (See appendix for an example set of Acceptance Criteria.) Initially these are all made available for volunteers to do freely. When GSoC rolls around we use them as suggested projects for students to undertake.
Any project that remains on the list unfinished for 6 months becomes eligible for funding the work. (This is so that any proposed projects that are fun or easy get done by volunteers, and money can be focused on harder unsexy work, and to make abuse harder.) We'll call these eligible projects 'jobs'.
2. Fundraising =============== Meanwhile, we run official fundraisers, that have the goal of getting donations for these jobs. Each of these has a named person serving as that fundraiser's coordinator who handles all administrative manners for the duration of the campaign. It is up to this coordinator's discretion how to distribute the raised money at the completion of the fundraiser, however: a) all funds must be directed only to jobs in the list, b) no single job can receive more than 25% of the raised funds, and c) no guarantee is made that the project will be undertaken if there is insufficient developer interest.
For ongoing fundraisers, the coordinator responsible for setting it up can specify the distribution programmatically (e.g. "distribute evenly to the four oldest jobs in the list", or "10% each to each to the ten jobs with the highest funding", or "allocated evenly across all documentation jobs". The coordinator will remain responsible for administrative duties for the length of the fundraiser; if they choose to step down, the fundraiser is terminated (but another coordinator can start up an equivalent to replace it, under their own funding distribution preferences).
3. Fundable Jobs ================= The money from these fundraisers goes to the Inkscape Foundation account administered by the Software Conservancy, who takes a small percentage of each donation. All donations are tax deductable. We maintain a list of allocations-to-jobs so we can keep track of what money "belongs" to which job, so the correct amount is paid when the job is done.
Anyone in the Inkscape AUTHORS file can sign up for one of the jobs. When they assign themselves the job, the clock starts ticking. During the time limit, no one else can sign up to do the same job. When the time runs out and the job is not completed, the assignee doesn't receive the reward and can't attempt the same job again for 6 months. The job is considered completed when the identified deliverables are delivered according to the specified criteria.
4. Completion Criteria ======================= The Reviewer makes the decision as to whether the job has been adequately completed, using the originally specified criteria.
By default, the Reviewer is the Fundraiser Coordinator; if the project was funded from multiple sources, the one that allocated the largest amount of funding (or their chosen delegate) is the Reviewer. This person must formally accept the Reviewer role by email within 1 week. For any reason, they may opt to decline the Reviewer role. If they are unresponsive or opt to decline the role, it passes to the next Fundraising Coordinator. If no Fundraising Coordinators take or delegate the role, then the original Project Proposer may take the Reviewer role (or delegate it to a person of their choice).
The Reviewer checks that the review criteria have been met.
5. Termination and Modification ================================ The original proposer of the Project or Job may withdraw it or modify its definition at any time, so long as someone is not signed up for it.
Unassigned Jobs expire 30 months after their initial project proposal. This is intended to clear out deadwood projects.
Any funds allocated to that job are moved to Inkscape's general fund.
6. Process Exceptions ====================== Historically, all development work funded by the Inkscape Project required authorization by the board; this funding model is to establish a structure for development funding that does not require board involvement. However, the board retains the ability to authorize exceptions for anything outside the bounds of this policy, to be handled on a case-by-case basis, with decisions made by a majority vote.
In particular, the board may select by vote certain projects to be immediately fundable, without needing to wait the normal 6 month period. They may also withdraw any project or job at any time, by majority vote.
The board may also make changes to this policy via a normal majority vote.
Appendix: Example Delivery and Acceptance Criteria =================================================== # This is a sample set of delivery and acceptance criteria; each project # may use, alter, or replace any of these conditions as appropriate.
a. Test cases are provided to add coverage for all newly added functionality.
b. Documentation patches provided for describing all newly added functionality.
c. Updates provided for release notes, NEWS, bug reports, etc.
d. All patch(es) have landed in the official upstream repository. Either in the mainline tree, or in an officially designated branch as per upstream policy.
e. Code builds and runs on the major platforms supported by the project.
f. Code passes the upstream project's designated style/lint checking tools.
g. User-visible strings are translatable as per project policy.
h. Unit and regression test suites pass with no new test failures.
At project completion, once the above criteria is met, 90% of the payable funds are delivered. 10% is held in reserve for bug fix followup: One month after completion, a list of up to 10 identified bugs can be specified by the Reviewer to be fixed; if all 10 are fixed within a month, the remaining 10% of the funding is released to the developer. If no bugs exist, or none are specified before 6 weeks after completion, then the developer is paid the 10% directly.
Open Questions: * How to do conflict resolution if there are problems or disagreements?
* What happens if one person signs up for the job, and someone else independently does the work?
Open Questions:
* Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
* Should jobs 'expire' after some period of time, with any allocated funds being freed up for other jobs and/or returned to the general fund?
* How do we prune out jobs that become irrelevant?
* What if someone (or multiple someones) handles the job without signing up for it?
Notes -----
Anti-Bounty ----------- A related but lesser-known type of payment is the anti-bounty, in which developers seek sponsors for work they want to do. According to Boris Mann of Bryght, who has completed at least one successful anti-bounty within the Drupal community, anti-bounties avoid many of the problems of normal bounties. Because they are posted by developers, Mann says, anti-bounties tend to be more realistic about scope, requirements, and costs. More importantly, because a developer is already interested in a project for which he posts an anti-bounty, Mann suggests that payment is less likely to destroy motivation or morale within a project, and more likely to result in a higher rate of completion than ordinary bounties. However, the concept does not appear widespread enough to draw definite conclusions from.
Developers post descriptions of projects to be done and payment desired. Sponsors can then select to contribute some or all of the funds to do the work.
Payment In Kind --------------- Developers post "wishlists" of things they'd like to receive - like computer equipment, books, travel expenses, etc. Links are included to appropriate stores to make payment easy.
Grants and Employment --------------------- Employers like redhat, etc. can directly hire, contract, or give grants to specific community members.
Fundraising Ideas ----------------- Forget all the traditional OSS project junk like cafepress, etc.
How about...
Inkscape Honey - from my Dad's bees, in ink jars
Pants. Everyone sells shirts, hats and underware. You can't go around in just shirts and underware.
Inkscape mouse and tablet
Thank you cards
Screwdriver
Pen and pencil set
VOIP hardware
GPS devices
Earrings