Sorry I have not taken the time for this yet. Hope to vote tomorrow evening.
regards, Johan On 11-5-2014 4:16, Bryce Harrington wrote: > Ping. We need a few more votes to reach a decision on this. > As this is an important change for the project, I'd ideally like to see > votes from all board members. > > Btw, I cast my vote as A. > > Bryce > > On Sun, May 04, 2014 at 05:33:17PM -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 >> ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/inkscape-board
