On Mon, May 12, 2014 at 01:18:31PM +0200, Tavmjong Bah wrote:
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.
Where is "second", "third"... ? I anticipated (and searched for) a
of requirements. I am left hanging. Either remove "First," or give me a
list, pretty please?
Yeah, that should be dropped. There used to be a condition that no more
than 25% of funds raised be allocated to any one project, as the second
requirement; everyone thought that was a weird requirement so I dropped
it but didn't copyedit out the 'First'.
On Sun, 2014-05-04 at 17:33 -0700, Bryce Harrington wrote:
> A majority vote of the current board members is required for this
> 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
> 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
> 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
> 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
> The Board may also make changes to this policy via a normal majority
> 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
> 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
> 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
> b. Documentation patches provided for describing all newly added
> 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
> f. Code passes the upstream project's designated style/lint checking
> 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
> * 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
> * 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
> 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