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

On Mon, May 12, 2014 at 11:34:22PM +0200, Johan Engelen wrote: > Hi all, > > I am confused about this sentence: > "Anyone in the Inkscape AUTHORS file is eligible to apply for a job." > > Is it meant to say, "only the people listed in AUTHORS...", or "also the > people listed in AUTHORS..." ? In other words, they need to be registered in the AUTHORS file in order to be eligible.

It's the same criteria we use for membership votes in board elections. The idea being we don't want just random riff raff applying for this work - it needs to be known people who have made contributions to Inkscape as community volunteers already. (If we have good contributors in the community who aren't in AUTHORS, then consider a side effect of this is to motivate us to ensure we get those people credited.) Bryce > Thanks, > Johan > > > On 5-5-2014 2:33, 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 >> >> >> ------------------------------------------------------------------------------ >> Is your legacy SCM system holding you back? Join Perforce May 7 to find out: >> • 3 signs your SCM is hindering your productivity >> • Requirements for releasing software faster >> • Expert tips and advice for migrating your SCM now >> http://p.sf.net/sfu/perforce >> _______________________________________________ >> Inkscape-board mailing list >> Inkscape-board(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-board >> >> > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Inkscape-board mailing list > Inkscape-board(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-board