[RFC] [UPDATED v.3] Proposal for fundraising and funded development process
Posting for one more review before we vote.
Please (please!) take an hour or two to study this over and give feedback. This is going to be a big change for Inkscape (hopefully!) and I want to make sure we're doing it in a way that it'll work well. Think of it from the perspective of someone running a fund raiser, someone proposing a project to be worked on, and someone who'll be doing the work.
Is this too much? Too little? Does it motivate you to hit the streets to drum up money, or make you want to tear your eyes? Ask the rules lawyer in you to see if there's any ways to abuse it. Call forth the grammar nazi in you while you're at it.
[Tony: I've incorporated changes that I hope address all the points you raised, but I'm not 100% confident that I was successful, as some of the concerns were sort of non-specific. Please re-review especially the limitation on Reviewer to contributing 50% or less of the funds; 50% is a WAG - tell me if it should be 0%, 10%, or what.]
Barring any major issues, I hope to get changes incorporated and this back out for voting within a couple weeks.
Bryce
Changes v3: * Reordered sections for clarity. Start with fundraising. * Discuss the duties of Fundraiser 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
------------------------------------------------------------------------
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 campaign, so long as a few requirements are met.
First, the person who organizes and supervises a fundraising campaign is termed a Fundraiser 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 Fundraiser Coordinator's discretion.
The second duty should be straightforward. All funds must be allocated to projects in the official Jobs List, with no more than 25% of the total raised funds going to any one project. 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).
The third duty - signing off on completion of the project - is described in more detail below. The Fundraiser 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 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'.
3. Fundable Jobs List ====================== 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 Fundraiser 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 original Project Proposer may take the Reviewer role (or delegate it to a person of their choice).
However the Reviewer is decided, the Reviewer can't have contributed more than 50% of the funds for the given project.
If someone other than the assigned Developer performs the work, to the satisfaction of the Reviewer, then the signed Developer will receive 70% of the funds. The remaining 30% are returned to the Inkscape general fund.
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 24 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 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.
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, Fundraisers, Reviewer, or Inkscape Board Member). For proper quorum, the Meeting must be attended by the Developer, the Project Proposer, the Reviewer, at least one Fundraiser, and one Neutral 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: 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.
On Sun, Feb 23, 2014 at 11:14:19PM -0800, Bryce Harrington wrote:
Posting for one more review before we vote.
If you prefer a diff against the last revision:
http://bazaar.launchpad.net/~inkscape.board/+junk/board-docs/revision/23
Bryce
On Sun, 2014-02-23 at 23:14 -0800, Bryce Harrington wrote:
Posting for one more review before we vote.
Please (please!) take an hour or two to study this over and give feedback. This is going to be a big change for Inkscape (hopefully!) and I want to make sure we're doing it in a way that it'll work well. Think of it from the perspective of someone running a fund raiser, someone proposing a project to be worked on, and someone who'll be doing the work.
Is this too much? Too little? Does it motivate you to hit the streets to drum up money, or make you want to tear your eyes? Ask the rules lawyer in you to see if there's any ways to abuse it. Call forth the grammar nazi in you while you're at it.
[Tony: I've incorporated changes that I hope address all the points you raised, but I'm not 100% confident that I was successful, as some of the concerns were sort of non-specific. Please re-review especially the limitation on Reviewer to contributing 50% or less of the funds; 50% is a WAG - tell me if it should be 0%, 10%, or what.]
Barring any major issues, I hope to get changes incorporated and this back out for voting within a couple weeks.
Bryce
Changes v3:
- Reordered sections for clarity. Start with fundraising.
- Discuss the duties of Fundraiser 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
Inkscape Funded Development Model ---------------------------------
- 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 campaign, so long as a few requirements are met.
First, the person who organizes and supervises a fundraising campaign is termed a Fundraiser 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
I assume that the fund-raising campaign is targeted to certain projects (e.g. bug squashing). b) doesn't limit the use of funds to those projects. Perhaps it should.
The first duty is left to the Fundraiser Coordinator's discretion.
The second duty should be straightforward. All funds must be allocated to projects in the official Jobs List, with no more than 25% of the total raised funds going to any one project. No guarantee is made that the project will be undertaken if there is insufficient developer interest.
Why the 25% limit? This precludes fund raising targeting a particular feature. (The 25% applies to an individual fund-raising campaign or to the total raised?)
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).
Being able to allocate funds automatically is a good idea. I'm not sure the examples are the best. For example, what if a new documentation job is added during the fund-raiser. Does it get a cut of the pie? What if I break up my documentation job into five pieces, does each of them get a cut of the pie? The 10% to the jobs with the highest funding seems to assume that the jobs have funding from other campaigns.
The third duty - signing off on completion of the project - is described in more detail below. The Fundraiser Coordinator *can't* do this if they personally contribute most of the funding, because it'd run us afoul of IRS rules.
- Proposing New Projects
========================== 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'.
- Fundable Jobs List
====================== 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 deductible. 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.
- Completion Criteria
======================= The Reviewer makes the decision as to whether the job has been adequately completed, using the originally specified criteria.
By default, the Fundraiser 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 original Project Proposer may take the Reviewer role (or delegate it to a person of their choice).
However the Reviewer is decided, the Reviewer can't have contributed more than 50% of the funds for the given project.
If someone other than the assigned Developer performs the work, to the satisfaction of the Reviewer, then the signed Developer will receive 70% of the funds. The remaining 30% are returned to the Inkscape general fund.
'signed' -> 'assigned'
- 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.
What happens to fund allocated to that job?
Unassigned Jobs expire 24 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.
- 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.
The Board may also make changes to this policy via a normal majority vote.
- 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, Fundraisers, Reviewer, or Inkscape Board Member). For proper quorum, the Meeting must be attended by the Developer, the Project Proposer, the Reviewer, at least one Fundraiser, and one Neutral 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: 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.
On Mon, Feb 24, 2014 at 03:32:36PM +0100, Tavmjong Bah wrote:
Hi Tav, just upfront let me say thank you for taking the time to review this. It's much appreciated!!!
On Sun, 2014-02-23 at 23:14 -0800, Bryce Harrington wrote:
Posting for one more review before we vote.
Please (please!) take an hour or two to study this over and give feedback. This is going to be a big change for Inkscape (hopefully!) and I want to make sure we're doing it in a way that it'll work well. Think of it from the perspective of someone running a fund raiser, someone proposing a project to be worked on, and someone who'll be doing the work.
Is this too much? Too little? Does it motivate you to hit the streets to drum up money, or make you want to tear your eyes? Ask the rules lawyer in you to see if there's any ways to abuse it. Call forth the grammar nazi in you while you're at it.
[Tony: I've incorporated changes that I hope address all the points you raised, but I'm not 100% confident that I was successful, as some of the concerns were sort of non-specific. Please re-review especially the limitation on Reviewer to contributing 50% or less of the funds; 50% is a WAG - tell me if it should be 0%, 10%, or what.]
Barring any major issues, I hope to get changes incorporated and this back out for voting within a couple weeks.
Bryce
Changes v3:
- Reordered sections for clarity. Start with fundraising.
- Discuss the duties of Fundraiser 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
Inkscape Funded Development Model ---------------------------------
- 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 campaign, so long as a few requirements are met.
First, the person who organizes and supervises a fundraising campaign is termed a Fundraiser 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
I assume that the fund-raising campaign is targeted to certain projects (e.g. bug squashing). b) doesn't limit the use of funds to those projects. Perhaps it should.
The fundraising campaigns don't need to announce that they're targeting specific projects, although nothing prevents them from doing so if they want. A fundraiser can declare that it's going to focus on funding projects geared towards bugfixing, and then wait to select the exact projects at the end. Or, it could choose to declare the exact projects it will support, with a pledge to limit its funding to just those projects; at the end if it turns out some of those can't be funded, then the fundraiser coordinator would need to pick something else.
Basically, what I'm trying to avoid is a situation where the board has to police the fundraisers. We set our interface to the point in time when the fundraiser is over, and the Fundraiser Coordinator looks at the still-open projects at that time, and allocates the funds to the project. I want to avoid putting constraints on how the F.C. makes his decisions. If he's pledged to his donors to fund projects A, B, C, D, then I'd leave it to him to actually do so; if it turns out project B got done on the side, and project D turned out to be unimplementable, and he has to instead pick A, C, E, F, then it'll be his rep on the line to explain to his donors why he didn't fund A, B, C, D - not ours.
The first duty is left to the Fundraiser Coordinator's discretion.
The second duty should be straightforward. All funds must be allocated to projects in the official Jobs List, with no more than 25% of the total raised funds going to any one project. No guarantee is made that the project will be undertaken if there is insufficient developer interest.
Why the 25% limit? This precludes fund raising targeting a particular feature. (The 25% applies to an individual fund-raising campaign or to the total raised?)
The 25% applies to an individual fundraising campaign.
Why the 25%? My thinking here is two-fold:
First, it serves to diffuse potential abuse. I imagine if we allow fundraisers that can 100% fund a specific project, then someone could abuse the system to introduce some sweetheart project for their friend, and then abuse the Inkscape name to raise a bunch of funds for it. By requiring funds to be distributed, this risk is reduced by a factor of 4.
Second, by forcing fundraiser coordinators to select four projects, it forces the funds to be applied to projects that otherwise might not get funded, thereby avoiding popularity contests. It also encourages defining multiple bite-size (but related) projects rather than lumping things together into a single big project unbrella.
But that said, I think this is the second or third time someone's flagged this as odd. If y'all think we should not restrict funds in this way it can easily be dropped.
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).
Being able to allocate funds automatically is a good idea. I'm not sure the examples are the best. For example, what if a new documentation job is added during the fund-raiser. Does it get a cut of the pie? What if I break up my documentation job into five pieces, does each of them get a cut of the pie? The 10% to the jobs with the highest funding seems to assume that the jobs have funding from other campaigns.
Thanks, I'll take another look at clarifying these examples.
The third duty - signing off on completion of the project - is described in more detail below. The Fundraiser Coordinator *can't* do this if they personally contribute most of the funding, because it'd run us afoul of IRS rules.
- Proposing New Projects
========================== 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'.
- Fundable Jobs List
====================== 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 deductible. 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.
- Completion Criteria
======================= The Reviewer makes the decision as to whether the job has been adequately completed, using the originally specified criteria.
By default, the Fundraiser 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 original Project Proposer may take the Reviewer role (or delegate it to a person of their choice).
However the Reviewer is decided, the Reviewer can't have contributed more than 50% of the funds for the given project.
If someone other than the assigned Developer performs the work, to the satisfaction of the Reviewer, then the signed Developer will receive 70% of the funds. The remaining 30% are returned to the Inkscape general fund.
'signed' -> 'assigned'
Thanks.
- 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.
What happens to fund allocated to that job?
If it's modified the funds stay with that job. If it's withdrawn the fund return to the general fund.
(Should it work different?)
Unassigned Jobs expire 24 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.
- 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.
The Board may also make changes to this policy via a normal majority vote.
- 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, Fundraisers, Reviewer, or Inkscape Board Member). For proper quorum, the Meeting must be attended by the Developer, the Project Proposer, the Reviewer, at least one Fundraiser, and one Neutral 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: 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.
On Sun, Feb 23, 2014 at 11:14:19PM -0800, Bryce Harrington wrote:
Posting for one more review before we vote.
The feedback from Tav and Tony led to extensive enough changes I'm going to do another v.4 post for review before voting. I'd love to get a bit more feedback into it before I post it though. If you haven't already please share your thoughts on it.
Btw, I'm also considering maybe posting this to inkscape-devel@ before we vote, so the development community at large has a chance to weigh in on it before anything's set in stone. Anyone feel strongly one way or the other about that?
Bryce
Please (please!) take an hour or two to study this over and give feedback. This is going to be a big change for Inkscape (hopefully!) and I want to make sure we're doing it in a way that it'll work well. Think of it from the perspective of someone running a fund raiser, someone proposing a project to be worked on, and someone who'll be doing the work.
Is this too much? Too little? Does it motivate you to hit the streets to drum up money, or make you want to tear your eyes? Ask the rules lawyer in you to see if there's any ways to abuse it. Call forth the grammar nazi in you while you're at it.
[Tony: I've incorporated changes that I hope address all the points you raised, but I'm not 100% confident that I was successful, as some of the concerns were sort of non-specific. Please re-review especially the limitation on Reviewer to contributing 50% or less of the funds; 50% is a WAG - tell me if it should be 0%, 10%, or what.]
Barring any major issues, I hope to get changes incorporated and this back out for voting within a couple weeks.
Bryce
Changes v3:
- Reordered sections for clarity. Start with fundraising.
- Discuss the duties of Fundraiser 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
Inkscape Funded Development Model ---------------------------------
- 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 campaign, so long as a few requirements are met.
First, the person who organizes and supervises a fundraising campaign is termed a Fundraiser 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 Fundraiser Coordinator's discretion.
The second duty should be straightforward. All funds must be allocated to projects in the official Jobs List, with no more than 25% of the total raised funds going to any one project. 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).
The third duty - signing off on completion of the project - is described in more detail below. The Fundraiser Coordinator *can't* do this if they personally contribute most of the funding, because it'd run us afoul of IRS rules.
- Proposing New Projects
========================== 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'.
- Fundable Jobs List
====================== 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.
- Completion Criteria
======================= The Reviewer makes the decision as to whether the job has been adequately completed, using the originally specified criteria.
By default, the Fundraiser 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 original Project Proposer may take the Reviewer role (or delegate it to a person of their choice).
However the Reviewer is decided, the Reviewer can't have contributed more than 50% of the funds for the given project.
If someone other than the assigned Developer performs the work, to the satisfaction of the Reviewer, then the signed Developer will receive 70% of the funds. The remaining 30% are returned to the Inkscape general fund.
- 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 24 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.
- 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.
The Board may also make changes to this policy via a normal majority vote.
- 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, Fundraisers, Reviewer, or Inkscape Board Member). For proper quorum, the Meeting must be attended by the Developer, the Project Proposer, the Reviewer, at least one Fundraiser, and one Neutral 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: 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.
Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-board mailing list Inkscape-board@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-board
On Thu, 2014-02-27 at 20:06 -0800, Bryce Harrington wrote:
Btw, I'm also considering maybe posting this to inkscape-devel@ before we vote, so the development community at large has a chance to weigh in on it before anything's set in stone. Anyone feel strongly one way or the other about that?
I think that's a good idea. While discussing OSS funding models is the easiest way I know to attract bike shedders, the potential for good comments and reducing surprise here is important.
I'm sure you know now to ignore the bike shedding :-)
Ted
participants (3)
-
Bryce Harrington -
Tavmjong Bah -
Ted Gould