[RFC] Proposal for handling fundraisers and funded development
Hi all,
The Inkscape board and SFC are interested in facilitating Inkscape progress by gathering donations for funding targeted development work.
Below is a draft of a plan for how we could do this. I've run this by the lawyers a couple times now, and informally presented it to the board for comment, but before we get any further, I'd like to open it up for public scrutiny. Once feedback has been incorporated, the next step will be to have our board officially vote on it, and put it into practice.
I've tried to model this as akin to a Summer of Code, except the projects are funded by our community through official fundraisers, and the work taken on by Inkscape developers rather than students. I think this could be very important to moving our project forward in a big way.
Please take a few moments to review this plan and share with me your questions or ideas on how it could be made better.
Thank you, Bryce
------------------------------------------------------------------------
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 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 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 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 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 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 the applicant files an application they may begin the job immediately, no vetting required. 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.
If someone other than the assigned Developer performs the work, to the satisfaction of the Reviewer, then the assigned 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. 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.
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, Fundraising Campaigns, Reviewer, or Inkscape Board Member). For proper quorum, the Meeting must be attended by the Developer, the Project Proposer, the Reviewer, at least one Fundraising Coordinator, 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.
Any comments?
Even just '+1 looks good to me' would be helpful to know.
Bryce
On Fri, Mar 21, 2014 at 08:57:00PM -0700, Bryce Harrington wrote:
Hi all,
The Inkscape board and SFC are interested in facilitating Inkscape progress by gathering donations for funding targeted development work.
Below is a draft of a plan for how we could do this. I've run this by the lawyers a couple times now, and informally presented it to the board for comment, but before we get any further, I'd like to open it up for public scrutiny. Once feedback has been incorporated, the next step will be to have our board officially vote on it, and put it into practice.
I've tried to model this as akin to a Summer of Code, except the projects are funded by our community through official fundraisers, and the work taken on by Inkscape developers rather than students. I think this could be very important to moving our project forward in a big way.
Please take a few moments to review this plan and share with me your questions or ideas on how it could be made better.
Thank you, Bryce
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 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 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 Fundraising 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 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 the applicant files an application they may begin the job immediately, no vetting required. 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.
- 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.
If someone other than the assigned Developer performs the work, to the satisfaction of the Reviewer, then the assigned 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. 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.
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, Fundraising Campaigns, Reviewer, or Inkscape Board Member). For proper quorum, the Meeting must be attended by the Developer, the Project Proposer, the Reviewer, at least one Fundraising Coordinator, 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.
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Good news! +1
El mié, 26-03-2014 a las 19:33 -0700, Bryce Harrington escribió:
Any comments?
Even just '+1 looks good to me' would be helpful to know.
Bryce
On Fri, Mar 21, 2014 at 08:57:00PM -0700, Bryce Harrington wrote:
Hi all,
The Inkscape board and SFC are interested in facilitating Inkscape progress by gathering donations for funding targeted development work.
Below is a draft of a plan for how we could do this. I've run this by the lawyers a couple times now, and informally presented it to the board for comment, but before we get any further, I'd like to open it up for public scrutiny. Once feedback has been incorporated, the next step will be to have our board officially vote on it, and put it into practice.
I've tried to model this as akin to a Summer of Code, except the projects are funded by our community through official fundraisers, and the work taken on by Inkscape developers rather than students. I think this could be very important to moving our project forward in a big way.
Please take a few moments to review this plan and share with me your questions or ideas on how it could be made better.
Thank you, Bryce
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 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 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 Fundraising 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 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 the applicant files an application they may begin the job immediately, no vetting required. 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.
- 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.
If someone other than the assigned Developer performs the work, to the satisfaction of the Reviewer, then the assigned 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. 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.
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, Fundraising Campaigns, Reviewer, or Inkscape Board Member). For proper quorum, the Meeting must be attended by the Developer, the Project Proposer, the Reviewer, at least one Fundraising Coordinator, 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.
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hello, sorry for the delay - I haven't had much time to read the proposal closely. It looks sensible, though I have a few comments.
2014-03-22 4:57 GMT+01:00 Bryce Harrington <bryce@...961...>:
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.
This section should contain a mention that while anyone can run a fundraiser, the possible fundraising goals are restricted by the list of available fundable proposals (is that correct?)
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 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).
What happens with the already collected funds when the coordinator steps down? Can the coordinator hand down the responsibility to someone else?
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.
- 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.
I think there should be some kind of description what is the process of approving these proposals, since as far as I understand the set of proposals determines the possible fundraising goals.
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 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 the applicant files an application they may begin the job immediately, no vetting required. 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.
- 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.
Does this imply that if there is a crowdsourcing campaign, the person that gives the biggest donation automatically becomes the 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.
If someone other than the assigned Developer performs the work, to the satisfaction of the Reviewer, then the assigned Developer will receive 70% of the funds. The remaining 30% are returned to the Inkscape general fund.
1. Who would determine whether someone else did the work, and how? 2. Isn't this a little unfair? Paying 70% for a job that was done by someone else seems a little excessive to me.
- 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.
There are several items which need doing but haven't been touched in 3 years or more, so I think this expiry process should be more "manual".
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.
Can an assigned, in-progress job be withdrawn?
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, Fundraising Campaigns, Reviewer, or Inkscape Board Member). For proper quorum, the Meeting must be attended by the Developer, the Project Proposer, the Reviewer, at least one Fundraising Coordinator, 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.
1. If the neutral developer is selected by the developer working on the job, is he really neutral? 2. The project proposer should not be required for the quorum, since in cases of long-standing unfixed issues (I think of things such as the inverted coordinate system or flowtext) the proposer may be unreachable. However, they should be contacted and allowed to provide input at the meeting.
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.
This requirement may be very hard to meet for GUI-related projects.
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.
1. I think that those 10% would be insufficient motivation for a follow-up. We should increase our emphasis on code quality, since the biggest problem for the project right now is the accumulated technical debt dating back to the Sodipodi days. I think that as much as 50% of the funds could be held back until bugs are resolved.
2. Limiting the list to 10 bugs seems arbitrary to me, and this limitation could be circumvented anyway by setting up "tracking bugs" that refer to multiple issues. I think there should be no limit on the number of bugs; if the developer thinks some of those bugs are unrelated to his work, then I presume the matter could in most cases be resolved amicably, otherwise there's the conflict resolution mechanism.
Regards, Krzysztof
On Thu, Mar 27, 2014 at 02:46:46PM +0100, Krzysztof Kosiński wrote:
Hello, sorry for the delay - I haven't had much time to read the proposal closely. It looks sensible, though I have a few comments.
- 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.
This section should contain a mention that while anyone can run a fundraiser, the possible fundraising goals are restricted by the list of available fundable proposals (is that correct?)
Yes, that's a good way to put it.
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 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).
What happens with the already collected funds when the coordinator steps down? Can the coordinator hand down the responsibility to someone else?
It's a very good question. We have a number of responsibilities placed on the fundraising coordinator which could last for a considerable time. I think having them delegate some/all responsibilities is going to be necessary. I'll add some language for this. Thanks.
- 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.
I think there should be some kind of description what is the process of approving these proposals, since as far as I understand the set of proposals determines the possible fundraising goals.
Alright, not a bad idea.
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'.
I think the right spot for approval is here, at the point the project turns into a 'job'. We could probably split it into a) mechanical check that all the fields are filled in, and b) conceptual review that it's a worthy idea likely to be accepted into the codebase and has been well-enough described.
- 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.
Does this imply that if there is a crowdsourcing campaign, the person that gives the biggest donation automatically becomes the reviewer?
No; it means if there were 5 crowdsourcing campaigns, and one of the 5 contributed more than the other 4, then whomever organized that one would be the Reviewer.
I'll work on this paragraph's phrasing some more.
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.
If someone other than the assigned Developer performs the work, to the satisfaction of the Reviewer, then the assigned Developer will receive 70% of the funds. The remaining 30% are returned to the Inkscape general fund.
- Who would determine whether someone else did the work, and how?
It would be judged by the same criteria as if the assigned Developer completed it.
- Isn't this a little unfair? Paying 70% for a job that was done by
someone else seems a little excessive to me.
Well, the thinking is that if you've followed the rules of the and are working on it, and some other developer ignores the rules and just commits their own implementation, it's not fair to the person doing the work.
This particular section has been flagged by a few other people as being weird. Perhaps we should just drop it, and just leave it undefined and rely on the board for deciding any conflicts.
- 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.
There are several items which need doing but haven't been touched in 3 years or more, so I think this expiry process should be more "manual".
Hmm, perhaps it could have an option to resubmit (retaining funds allocated), perhaps requiring some extra clarification or review.
- 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.
Can an assigned, in-progress job be withdrawn?
With a majority vote of the Board, yes.
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, Fundraising Campaigns, Reviewer, or Inkscape Board Member). For proper quorum, the Meeting must be attended by the Developer, the Project Proposer, the Reviewer, at least one Fundraising Coordinator, 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.
- If the neutral developer is selected by the developer working on
the job, is he really neutral?
Perhaps Neutral is not the right word, I meant in the sense of being uninvolved in the project so far. It's expected this person would be on the Developer's side.
- The project proposer should not be required for the quorum, since
in cases of long-standing unfixed issues (I think of things such as the inverted coordinate system or flowtext) the proposer may be unreachable. However, they should be contacted and allowed to provide input at the meeting.
Well, the count of 5 people is deliberate to ensure there are no tie votes. But I'll give this some more thought; you're right that project proposals could be "drive by".
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.
This requirement may be very hard to meet for GUI-related projects.
This section is just for example. However, many GUI projects include chunks of internal code that may well benefit from tests.
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.
- I think that those 10% would be insufficient motivation for a
follow-up. We should increase our emphasis on code quality, since the biggest problem for the project right now is the accumulated technical debt dating back to the Sodipodi days. I think that as much as 50% of the funds could be held back until bugs are resolved.
- Limiting the list to 10 bugs seems arbitrary to me, and this
limitation could be circumvented anyway by setting up "tracking bugs" that refer to multiple issues. I think there should be no limit on the number of bugs; if the developer thinks some of those bugs are unrelated to his work, then I presume the matter could in most cases be resolved amicably, otherwise there's the conflict resolution mechanism.
Good points. This paragraph is provided just as an example, and it's expected that projects would customize it to their preferences. That said, even though it's just "sample text" it should be written with a mind to best practices, and you're right on both counts. I'll revamp it incorporating your suggestions.
Thanks for giving feedback! Bryce
participants (3)
-
Bryce Harrington -
Jabiertxo Arraiza Cenoz -
Krzysztof Kosiński