Re: [Inkscape-board] [REFERENDUM] Inkscape Funded Development Model

I vote A. I would like to echo Josh and also thank all those that contributed. I do have a minor quibble with the text. In the section 1.: "..so long as a few requirements are met. First, the...." Where is "second", "third"... ? I anticipated (and searched for) a list of requirements. I am left hanging. Either remove "First," or give me a list, pretty please?

Tav On Sun, 2014-05-04 at 17:33 -0700, Bryce Harrington wrote: > A majority vote of the current board members is required for this > matter. > > Proposal: > > 1. Adoption of the procedure described below for handling fundraisers > and funded development work. > > 2. Board chairman will document this procedure on the Inkscape > website, and announce to the developer and user mailing lists. > > [ ] a. Yes, adopt this procedure and announce it > [ ] b. No, do not adopt this procedure > > > ------------------------------------------------------------------------ > [See Appendix B for changes made based on feedback from Inkscape community.] > > > Inkscape Funded Development Model > --------------------------------- > > 1. Fundraising > =============== > > Using the model we'll describe below, anyone may start an official > fundraiser for Inkscape development. We leave it to your imagination > how to structure and run your fundraising campaign, and empower you with > selecting from a list of defined development goals to fund, so long as a > few requirements are met. > > First, the person who organizes and supervises a fundraising campaign is > termed a Fundraising Coordinator. We may have multiple coordinators if > we have multiple campaigns, but only one coordinator per fundraiser. > They have three duties: > > a) Administration of the fundraiser > b) Allocate raised funds to projects > c) (Optionally) Be involved in final signoff of completed projects > > The first duty is left to the Fundraising Coordinator's discretion. > > The second duty should be straightforward. When the fundraiser is > completed, all funds must be allocated to one or more projects in the > official Jobs List. No guarantee is made that any given project will be > undertaken if there is insufficient developer interest, but future > fundraisers can up the funds allocated to it to stimulate interest. > > We expect some campaigns will wish to target one or more specific > projects, and announce this upfront to stimulate donations. This is > fine to do, but keep in mind that projects can change (or get > implemented) while the campaign is under way. So instead of naming > specific projects, it may be better to describe the types of projects > the campaign is aiming to fund, and make the specific decision(s) when > the fundraiser is over. > > For ongoing fundraisers, the coordinator responsible for setting it up > can specify the distribution programmatically (e.g. "distribute evenly > to the four oldest projects in the list as of the end of the campaign", > or "10% to each of the ten projects with the highest funding from past > campaigns", or "allocated evenly across all documentation projects > registered as of the start of this campaign". The coordinator will > remain responsible for administrative duties both during and after the > fundraiser. Should they need to step down, they may name a replacement > to hand the remaining duties down to. If they disappear without naming > a replacement, or if there are any other irregularities or questions, > the issue should be escalated to the Inkscape Board for resolution. > > The third duty - signing off on completion of the project - is described > in more detail below. The Fundraising Coordinator *can't* do this if > they personally contribute most of the funding, because it'd run us > afoul of IRS rules. > > > 2. Proposing New Projects > ========================== > We maintain a listing of proposed (unfunded) projects. Anything can be > proposed, including feature development, bug triaging, documentation, > administration, etc. but it must include a detailed description (>100 > words) of the work to be done. Anyone may adopt these projects as > regular (unfunded) development tasks, GSoC projects, etc. (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.) > > Once a proposed project has reached a certain age, it will be eligible > for funding. We'll call these eligible projects 'jobs', once they meet > the following conditions: > > a. Has been on the Proposed Projects list for >=6 months > b. A Deliverable has been defined > c. Acceptance Criteria has been defined (see appendix) > d. A Time Limit has been estimated for how long the work should take > e. Proposal has been Seconded by another Developer that the proposed > change is, in concept, worth including in the Inkscape codebase > > Once a proposal meets all 5 of these conditions it is considered an > Approved Job. > > > 3. Fundable Jobs List > ====================== > The money from these fundraisers goes to the Inkscape Foundation account > administered by the Software Freedom Conservancy, who takes a small > percentage of each donation. Conservancy is a US 501(c)(3) public > charity, and all donations are tax deductible in the United States as > allowed by law. > > 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. This amount is displayed on the web for developers to browse > when selecting a job to do. > > Anyone in the Inkscape AUTHORS file is eligible to apply for a job. > The applicant must submit a Job Proposal, which will identify the > applicant's qualifications for doing the job, and outline how they > intend to do the implementation. > > The Inkscape Board will delegate one of its members to review and vet > applicants to help ensure the best candidates are selected for each job. > For larger, longer, or more complicated jobs the vetting may take some > time, but for moderate sized jobs the intent is for a decision to be > made within a few days. The Inkscape Board may elect to mark some jobs > (such as smaller ones) as Pre-Approved; once an applicant files an > application they may begin the job immediately, no vetting required. > Board members are excepted from this process due to conflict of > interest; they may apply for the jobs but must still be vetted. > No one may assign themselves more than one Pre-Approved job at a time, > and the Board reserves the right to subsequently review the application > and disapprove it in case of problems. > > When an applicant is assigned the job, the clock starts ticking. The > applicant must post at least one progress report each month (e.g. to a > blog or to the Inkscape wiki). During the time limit, so long as the > monthly reports are being clearly posted, no one else can apply to do > the same job. If two months pass without a report, or when the 6 months > time runs out, and the job is not completed, the assignee doesn't > receive the funds 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 Fundraising Coordinator is the Reviewer; 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 Inkscape Board will delegate a Reviewer. > > However the Reviewer is decided, he or she must be a different person > than the original Project Proposer, and neither the Reviewer nor the > Reviewer's employer may contribute more than 50% of the total funds for > the given project. We want to avoid a situation where a person or their > employer has an independent business interest in seeing the job > completed, and is over-involved in the management of the work. > > > 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. > If the Project is withdrawn, all funds allocated to it return to the > general Inkscape fund. > > Unassigned Jobs expire 24 months after their initial project proposal. > This is intended to clear out deadwood projects and to encourage > developers to adopt projects with allocated funds before they expire, > and to discourage proposing projects that are unlikely to get attention > in 24 months. Any funds allocated to untaken jobs are moved to > Inkscape's general fund. > > At its discretion, by majority vote the board may elect to extend the > expiration date of about-to-expire Jobs with funds allocated by 12 > months. > > > 6. Process Exceptions > ====================== > Historically, all development work funded by the Inkscape Project > required authorization by the Inkscape Board of Directors; 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, > including even assigned, in-progress jobs (though this should be highly > unusual). > > The Board may also make changes to this policy via a normal majority > vote. > > > 7. Conflict Resolution > ======================= > If there are any problems or disagreements once a project has been > assigned to a Developer, a Meeting can be called by any stakeholder > (Project Proposer, Developer, Fundraising Campaigns, Reviewer, or > Inkscape Board Member). For proper quorum, at a minimum the Meeting > must be attended by the Developer, either the Project Proposer or the > Reviewer, at least one Fundraising Coordinator involved in the funding > of the project, any one Board Member, and a Colleague Developer (whom > can be anyone in the Inkscape AUTHORS file selected by the Developer). > Any unanimous decision reached in this Meeting is binding on all > parties. > > Any conflict that can't be resolved via a Meeting may then be escalated > to the Inkscape Board of Directors, who will be the ultimate arbiter. > > Conflicts of interest, including conflicts with the board, are governed > by the Software Freedom Conservancy's org-wide conflict of interest > policy. > > > > Appendix A: 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, 70% of the > payable funds are delivered. 30% is held in reserve for bug fix > followup: One month after completion, a list of identified bugs can be > specified by the Reviewer to be fixed; if all are fixed within a month, > the remaining 30% 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 remainder directly. > > > Appendix B: Changelog > ===================== > Changes v5 > * Exclude the board from pre-approved jobs, to avoid conflict of > interest. > * Drop the section for handling the case where a non-assigned > developer does the assigned task. This will probably be an unusual > situation, and the board can decide on a case-by-case basis. > * In the example Acceptance Criteria, adjusted payments to 70% for > project completion and 30% for bugfix / final acceptance. Don't > set a limit to the number of bug reports; this should be determined > organically - in case of abuse there is a conflict resolution > mechanism available. > * In the opening paragraph clarify that the allowed development goals > are selected from a pre-defined list. > * Elaborate on how a rough proposed idea becomes an approved job for > selection. > * Jobs that are about to expire can be extended 12 months by a > majority Board vote. > * For Conflict Resolution, renamed 'Neutral Developer' to 'Colleague > Developer', since this person is selected by the Developer and thus > likely will be partial to their cause; 'Neutral' would suggest a > level of impartiality which is neither realistic nor really > necessary. > > Changes v4: > * Drop the requirement for allocating no more than 25% per project. > * If a project is withdrawn by its original proposer, any money > allocated for it goes back to the general pool. > * Avoid ambiguous "Fundraiser" verbage. Use either "Fundraising > Coordinator" or "Fundraising Campaign". > * Fix Software Freedom Conservancy name. > * Give advice on allocation of funds to projects to not be too > specific upfront. > * Require job applicants to submit applications, which will be vetted > and approved by the board. Allow board to delegate this work to an > elected member. Allow for smaller tasks to be marked Pre-Approved, > that can be undertaken with no vetting. > * Require job assignees to post monthly progress reports, or else > job can be reassigned to someone else. > * Prohibit the Project Proposer from also being the Reviewer. > * Prohibit person from being a Reviewer if they or their employer > contributed over half the funds. > * Various spelling and grammar fixes. > > Changes v3: > * Reordered sections for clarity. Start with fundraising. > * Discuss the duties of Fundraising Coordinators in more detail. > * Reviewers cannot have contributed more than 50% of the funds for the > project. This is due to IRS restrictions we must follow in order to > remain covered as non-profit. "50%" is just a WAG and may need > adjusted down (possibly to 0%) pending legal advice from SFC. > * Expire unassigned jobs after 24 months rather than 30. > * Note that SFC can be used for resolving conflicts of interest. > > Changes v2: > * 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