Proposal for fundraising and funded development process (Was Re: RedHat Question)
[Forwarding thread to the board mailing list. Dropping CC of board members since they're already on the list alias.]
We've talked about fundraisers and funded development in the past. For me the sticking point is always, "Who's going to handle running the fundraiser, and then judging whether the work was adequately done?"
So, I did a bit of brainstorming using Krzysztof's task rule as a starting point, tacking on the thoughts I mentioned earlier, and fleshing out how the fundraising and administration end of things could be done.
My goal here is to get us to a point where the board doesn't have to be intimately involved in specific jobs and fundraisers, but can just sign off on an official policy for how they should be handled in general, and then let the work happen organically.
Please read this over and throw darts. I have several questions that I'd want to see answers for before putting this up for a vote, so do please chime in with your opinions and thoughts.
Bryce
------------------------------------------------------------------------
We maintain a listing of proposed projects. Projects can be proposed by anyone in the Inkscape AUTHORS file. 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. 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'.
Meanwhile, we run official fundraisers, that have the goal of getting donations for these jobs. Each of these has a named person serving as that fundraiser's coordinator who handles all administrative manners for the duration of the campaign. It is up to this coordinator's discretion how to distribute the raised money at the completion of the fundraiser, however: a) all funds must be directed only to jobs in the list, and b) no single job can receive more than 25% of the raised funds.
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 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.
Open Questions:
* Should fundraiser coordinators get remuneration of some sort, or is the ability to direct the funds they raise a sufficient reward?
* Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
* Should jobs 'expire' after some period of time, with any allocated funds being freed up for other jobs and/or returned to the general fund?
* How do we prune out jobs that become irrelevant?
* What if someone (or multiple someones) handles the job without signing up for it?
------------------------------------------------------------------------
On Fri, Dec 13, 2013 at 11:40:18PM +0100, Krzysztof Kosiński wrote:
Hello all
Chiming in with a slight delay. It would be awesome if we could get that funding.
If we want to use the money to fund people working on specific features or maintenance tasks, I could help outline the goals for that, and probably also do some of the tasks myself if I have the time.
If RedHat were to provide recurring contributions, we could set up a program where performing a well defined coding task in a specified time limit is rewarded with money. The crucial difference between this and GSoC would be that we could use our program to pay people doing boring maintenance tasks such as removing deprecated functions and writing better documentation.
When it comes to rules, I would imagine something like this: Any existing committer could sign up to do one of the tasks, and the clock would start ticking. During the specified time limit, no one else can sign up to do the same task. When the time runs out and the task is not completed, the committer who signed up doesn't receive the reward and can't attempt the same task again for e.g. one year.
Regards, Krzysztof
2013/12/10 Tavmjong Bah <tavmjong@...47...>:
On Mon, 2013-12-09 at 14:38 -0500, Martin Owens wrote:
Hey Guys,
More discussion with Máirín (mo) at RedHat. See below.
On Mon, 2013-12-09 at 14:18 -0500, Máirín Duffy wrote:
Okay, and are you guys going to be paying someone to develop the features you're looking at? Are you doing it through a program or as a one-off kind of thing?
I think this is something the board should talk about. I know it entirely depends on the amount of funds and the scale of participation. But it might be worth having a couple of levels of 'we wish we could do this if we had this amount of funding'
And should it be a program? The Inkscape-Equivalence program. Donate the same amount per year as you would pay for Illustrator to help the inkscape project development.?
I like the idea of the "Inkscape-Equivalence' program. I think we should make it a permanent program. Do other groups do this?
Tav
On Fri, Dec 20, 2013 at 4:56 PM, Bryce Harrington <bryce@...2...> wrote:
My goal here is to get us to a point where the board doesn't have to be intimately involved in specific jobs and fundraisers, but can just sign off on an official policy for how they should be handled in general, and then let the work happen organically.
Definitely ideal.
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'.
Here's my hesitation on the 6 month funding wait (at least for the first batch of ideas, or specific ones). If there is something that is in dire need of a rewrite or otherwise is a maintenance task that requires extensive knowledge of the codebase, I think we should not hold off on these potentially getting funded. What if one of those big tasks is identified and someone with the skill and knowledge finds the time that they won't have 6 months out? I do think it's preferable to have things done by volunteers, but I don't want us to miss out if those unappealing and less fun things can get completed.
Open Questions:
- Should fundraiser coordinators get remuneration of some sort, or is the ability to direct the funds they raise a sufficient reward?
I don't know that it's easy to decide this until we find out how much time is required... then again, they do really get to allocate things toward something that they might favor. :-/
- Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
Is this something that the fundraising coordinator should be tasked with or perhaps be the person who proposed the job be the one to review?
- Should jobs 'expire' after some period of time, with any allocated funds being freed up for other jobs and/or returned to the general fund?
I would lean toward yes for expiration. If there is no deadline to get donations in by, there is no demand to donate now. However, we'd really have to disclaimer up and down that it's not guaranteed to get funded, and unlike kickstarter, your money is transferred regardless of the campaign results.
- How do we prune out jobs that become irrelevant?
I think if it appears to have become irrelevant, we have the job proposer re-review the status and close it out as such. One question is what happens to funds acquired that were potentially going toward that job.
- What if someone (or multiple someones) handles the job without signing up for it?
This was a question I had related to the last question. What if the job became irrelevant because of overlap from another task? In that situation, perhaps if there were funds already allocated toward it, as a one time thank you, the coordinator could offer to pay a portion as a reward? My thought is that would raise awareness, but the dev(s) wouldn't be able to use the excuse again that they didn't know about the jobs.
I think that if it seems like the jobs thing is going to be a viable and healthy way to get things accomplished, we can be more vocal about it. To a good degree, our core devs should be fully aware of the list and the process. To devs seeking to get paid to work on any project that they're not familiar with (let's say by a 3rd party, privately), one would hope they would get in contact with the mailing list or a core developer first. Lastly, for new developers to the project, whether potential students for GSoC, or new faces who post patches in the tracker or link a branch they've been working on, we can make them aware of the list.
Just some thoughts...
Cheers, Josh
On Sun, Dec 22, 2013 at 12:01:22PM -0800, Josh Andler wrote:
On Fri, Dec 20, 2013 at 4:56 PM, Bryce Harrington <bryce@...2...> wrote:
My goal here is to get us to a point where the board doesn't have to be intimately involved in specific jobs and fundraisers, but can just sign off on an official policy for how they should be handled in general, and then let the work happen organically.
Definitely ideal.
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'.
Here's my hesitation on the 6 month funding wait (at least for the first batch of ideas, or specific ones). If there is something that is in dire need of a rewrite or otherwise is a maintenance task that requires extensive knowledge of the codebase, I think we should not hold off on these potentially getting funded. What if one of those big tasks is identified and someone with the skill and knowledge finds the time that they won't have 6 months out? I do think it's preferable to have things done by volunteers, but I don't want us to miss out if those unappealing and less fun things can get completed.
Good point. Perhaps we could allow waiving the 6 month requirements for particular jobs, via a majority board vote?
For the initial batch of ideas, we could have each board member go through the list and vote yea/nay for granting an exception to the 6-month rule. That'd hopefully give us half a dozen or so to seed the job jar with.
Open Questions:
- Should fundraiser coordinators get remuneration of some sort, or is the ability to direct the funds they raise a sufficient reward?
I don't know that it's easy to decide this until we find out how much time is required... then again, they do really get to allocate things toward something that they might favor. :-/
- Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
Is this something that the fundraising coordinator should be tasked with or perhaps be the person who proposed the job be the one to review?
Possibly, although I worry that a good bit of time could pass between the proposal, the fundraiser, and the execution of the job, and both the proposer and fundraiser coordinator could drift away. Also, they may not have the technical skill or time/interest in doing the final review.
- Should jobs 'expire' after some period of time, with any allocated funds being freed up for other jobs and/or returned to the general fund?
I would lean toward yes for expiration. If there is no deadline to get donations in by, there is no demand to donate now. However, we'd really have to disclaimer up and down that it's not guaranteed to get funded, and unlike kickstarter, your money is transferred regardless of the campaign results.
*Nod* Good points.
- How do we prune out jobs that become irrelevant?
I think if it appears to have become irrelevant, we have the job proposer re-review the status and close it out as such. One question is what happens to funds acquired that were potentially going toward that job.
Having the job proposer do it sounds like a decent strategy. We should also think about letting the job proposer update the job definition.
I guess worst case the board could also just annually do a review of old ones and vote on keeping or dropping them. Ideally there shouldn't be many jobs that reach this point; if there are, then there may be bigger problems at work, and the board would need to investigate anyway...
Do you think having the funds just go into the regular inkscape funds would be appropriate? Or should the funds be redistributed to the other jobs?
- What if someone (or multiple someones) handles the job without signing up for it?
This was a question I had related to the last question. What if the job became irrelevant because of overlap from another task? In that situation, perhaps if there were funds already allocated toward it, as a one time thank you, the coordinator could offer to pay a portion as a reward? My thought is that would raise awareness, but the dev(s) wouldn't be able to use the excuse again that they didn't know about the jobs.
I think that if it seems like the jobs thing is going to be a viable and healthy way to get things accomplished, we can be more vocal about it. To a good degree, our core devs should be fully aware of the list and the process. To devs seeking to get paid to work on any project that they're not familiar with (let's say by a 3rd party, privately), one would hope they would get in contact with the mailing list or a core developer first. Lastly, for new developers to the project, whether potential students for GSoC, or new faces who post patches in the tracker or link a branch they've been working on, we can make them aware of the list.
Just some thoughts...
Cheers, Josh
Bryce
On Mon, 2013-12-23 at 03:11 +0000, Bryce W. Harrington wrote:
On Sun, Dec 22, 2013 at 12:01:22PM -0800, Josh Andler wrote:
On Fri, Dec 20, 2013 at 4:56 PM, Bryce Harrington <bryce@...2...> wrote:
My goal here is to get us to a point where the board doesn't have to be intimately involved in specific jobs and fundraisers, but can just sign off on an official policy for how they should be handled in general, and then let the work happen organically.
Definitely ideal.
+1
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'.
Here's my hesitation on the 6 month funding wait (at least for the first batch of ideas, or specific ones). If there is something that is in dire need of a rewrite or otherwise is a maintenance task that requires extensive knowledge of the codebase, I think we should not hold off on these potentially getting funded. What if one of those big tasks is identified and someone with the skill and knowledge finds the time that they won't have 6 months out? I do think it's preferable to have things done by volunteers, but I don't want us to miss out if those unappealing and less fun things can get completed.
Good point. Perhaps we could allow waiving the 6 month requirements for particular jobs, via a majority board vote?
For the initial batch of ideas, we could have each board member go through the list and vote yea/nay for granting an exception to the 6-month rule. That'd hopefully give us half a dozen or so to seed the job jar with.
+1
We might also exempt ideas that have been around for awhile.
Open Questions:
- Should fundraiser coordinators get remuneration of some sort, or is the ability to direct the funds they raise a sufficient reward?
I don't know that it's easy to decide this until we find out how much time is required... then again, they do really get to allocate things toward something that they might favor. :-/
I tend to think the ability to direct the funds is enough reward, but we could reevaluate at some point. I don't envision that the level of involvement should reach the GSoC mentor level where it is expected that the students will need help.
- Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
Is this something that the fundraising coordinator should be tasked with or perhaps be the person who proposed the job be the one to review?
Possibly, although I worry that a good bit of time could pass between the proposal, the fundraiser, and the execution of the job, and both the proposer and fundraiser coordinator could drift away. Also, they may not have the technical skill or time/interest in doing the final review.
Definitely interactive. Fundraiser has first priority with some kinkd of backup. There needs to be some kind of conflict resolution process defined.
- Should jobs 'expire' after some period of time, with any allocated funds being freed up for other jobs and/or returned to the general fund?
I would lean toward yes for expiration. If there is no deadline to get donations in by, there is no demand to donate now. However, we'd really have to disclaimer up and down that it's not guaranteed to get funded, and unlike kickstarter, your money is transferred regardless of the campaign results.
*Nod* Good points.
+1
- How do we prune out jobs that become irrelevant?
I think if it appears to have become irrelevant, we have the job proposer re-review the status and close it out as such. One question is what happens to funds acquired that were potentially going toward that job.
Having the job proposer do it sounds like a decent strategy. We should also think about letting the job proposer update the job definition.
I guess worst case the board could also just annually do a review of old ones and vote on keeping or dropping them. Ideally there shouldn't be many jobs that reach this point; if there are, then there may be bigger problems at work, and the board would need to investigate anyway...
Do you think having the funds just go into the regular inkscape funds would be appropriate? Or should the funds be redistributed to the other jobs?
Either would be fine, as long as it is well specified in advance.
- What if someone (or multiple someones) handles the job without signing up for it?
If you don't sign up for it, you don't get the reward. You can always sign up at the last minute if the job has not been already taken. The problem is how to handle the case where someone else has already taken the job.
This was a question I had related to the last question. What if the job became irrelevant because of overlap from another task? In that situation, perhaps if there were funds already allocated toward it, as a one time thank you, the coordinator could offer to pay a portion as a reward? My thought is that would raise awareness, but the dev(s) wouldn't be able to use the excuse again that they didn't know about the jobs.
I think that if it seems like the jobs thing is going to be a viable and healthy way to get things accomplished, we can be more vocal about it. To a good degree, our core devs should be fully aware of the list and the process. To devs seeking to get paid to work on any project that they're not familiar with (let's say by a 3rd party, privately), one would hope they would get in contact with the mailing list or a core developer first. Lastly, for new developers to the project, whether potential students for GSoC, or new faces who post patches in the tracker or link a branch they've been working on, we can make them aware of the list.
Just some thoughts...
Cheers, Josh
Bryce
On 23-12-2013 4:11, Bryce W. Harrington wrote:
On Sun, Dec 22, 2013 at 12:01:22PM -0800, Josh Andler wrote:
On Fri, Dec 20, 2013 at 4:56 PM, Bryce Harrington
- Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
Is this something that the fundraising coordinator should be tasked with or perhaps be the person who proposed the job be the one to review?
Possibly, although I worry that a good bit of time could pass between the proposal, the fundraiser, and the execution of the job, and both the proposer and fundraiser coordinator could drift away. Also, they may not have the technical skill or time/interest in doing the final review.
When is the work committed to trunk? ("committed to trunk" could be a very clear flag for job completion) Some refactoring projects may be best suited as a set of individual patches, instead of one big patch. That makes it much easier for bug tracking I think.
The reviewer role should not be too large I feel (otherwise we will have trouble finding reviewers). One concern is that the reviewer might feel very pressured about his decision. It's about giving someone money, or not, and might end up with tough decisions. (What if the job is complete and all works well, but the coding style conflicts quite a lot with ours... and then the dev says it will take too much time to fix that and... community screams: gogo, commit already! etc...)
regards, Johan
On Wed, Jan 08, 2014 at 09:17:59PM +0100, Johan Engelen wrote:
On 23-12-2013 4:11, Bryce W. Harrington wrote:
On Sun, Dec 22, 2013 at 12:01:22PM -0800, Josh Andler wrote:
On Fri, Dec 20, 2013 at 4:56 PM, Bryce Harrington
- Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
Is this something that the fundraising coordinator should be tasked with or perhaps be the person who proposed the job be the one to review?
Possibly, although I worry that a good bit of time could pass between the proposal, the fundraiser, and the execution of the job, and both the proposer and fundraiser coordinator could drift away. Also, they may not have the technical skill or time/interest in doing the final review.
When is the work committed to trunk? ("committed to trunk" could be a very clear flag for job completion) Some refactoring projects may be best suited as a set of individual patches, instead of one big patch. That makes it much easier for bug tracking I think.
Theoretically refactoring could be done on a side branch and then merged. However, this is often easier said than done, in that if the mainline code changes even a little, it can cause a conflicted merge for the refactored code, resulting in a painful manual merge.
So, ideally it would be nice if the system was designed to permit continuous merging to mainline, throughout the development process.
The reviewer role should not be too large I feel (otherwise we will have trouble finding reviewers). One concern is that the reviewer might feel very pressured about his decision. It's about giving someone money, or not, and might end up with tough decisions. (What if the job is complete and all works well, but the coding style conflicts quite a lot with ours... and then the dev says it will take too much time to fix that and... community screams: gogo, commit already! etc...)
Very good points, and that does sound like a realistic scenario we'd probably hit a lot.
Or, they neglected to make the strings translatable. Or developed only on Linux and introduced platform issues for OSX/Windows that only show up after it's in mainline. Or adds a performance impact.
I suppose some of that is just technical debt we would absorb as a project as the cost for gaining the paid development, and handled through our regular open source community efforts, as happens with delivered GSoC projects. And ideally the developer would stick around to support their code.
For some of this, we leverage development tools. For instance, make one criterion be that it passes lint or some code style checker. And lean a lot on our test suite. So, the review job becomes more like a checklist.
Bryce
On Wed, 2014-01-08 at 17:05 -0800, Bryce Harrington wrote:
Or, they neglected to make the strings translatable. Or developed only on Linux and introduced platform issues for OSX/Windows that only show up after it's in mainline. Or adds a performance impact.
Part of the packet of information could include strong recommendations to factor in some resources dealing with any after bugs. Some guidelines such as: We recommend that you price in a 10% increase to deal with issues that may crop up after you have delivered code.
We can't guarantee anything; but at least we can reasonably ask developers to take responsibility as they're given fair warning to factor some of that cost in too.
Martin,
On 9-1-2014 5:08, Martin Owens wrote:
On Wed, 2014-01-08 at 17:05 -0800, Bryce Harrington wrote:
Or, they neglected to make the strings translatable. Or developed only on Linux and introduced platform issues for OSX/Windows that only show up after it's in mainline. Or adds a performance impact.
Part of the packet of information could include strong recommendations to factor in some resources dealing with any after bugs. Some guidelines such as: We recommend that you price in a 10% increase to deal with issues that may crop up after you have delivered code.
We can't guarantee anything; but at least we can reasonably ask developers to take responsibility as they're given fair warning to factor some of that cost in too.
That's a good idea. Maybe some "1-month after commit" review for larger projects, to see if there is anything left to mop up.
-Johan
On Thu, Jan 09, 2014 at 07:58:15PM +0100, Johan Engelen wrote:
On 9-1-2014 5:08, Martin Owens wrote:
On Wed, 2014-01-08 at 17:05 -0800, Bryce Harrington wrote:
Or, they neglected to make the strings translatable. Or developed only on Linux and introduced platform issues for OSX/Windows that only show up after it's in mainline. Or adds a performance impact.
Part of the packet of information could include strong recommendations to factor in some resources dealing with any after bugs. Some guidelines such as: We recommend that you price in a 10% increase to deal with issues that may crop up after you have delivered code.
We can't guarantee anything; but at least we can reasonably ask developers to take responsibility as they're given fair warning to factor some of that cost in too.
That's a good idea. Maybe some "1-month after commit" review for larger projects, to see if there is anything left to mop up.
Yeah, I like the sound of this. So then the 10% would be paid after the 1-month period, for fixing some number of bugs? I suppose if there's no bugs reported, they just get it as a bonus? :-)
Bryce
So, I don't have specific comments, but in general I think we should try. So many of these type of programs have been unsuccessful in the past it makes me a bit pessimistic. But I do really want one to work.
Ted
On Fri, 2013-12-20 at 16:56 -0800, Bryce Harrington wrote:
[Forwarding thread to the board mailing list. Dropping CC of board members since they're already on the list alias.]
We've talked about fundraisers and funded development in the past. For me the sticking point is always, "Who's going to handle running the fundraiser, and then judging whether the work was adequately done?"
So, I did a bit of brainstorming using Krzysztof's task rule as a starting point, tacking on the thoughts I mentioned earlier, and fleshing out how the fundraising and administration end of things could be done.
My goal here is to get us to a point where the board doesn't have to be intimately involved in specific jobs and fundraisers, but can just sign off on an official policy for how they should be handled in general, and then let the work happen organically.
Please read this over and throw darts. I have several questions that I'd want to see answers for before putting this up for a vote, so do please chime in with your opinions and thoughts.
Bryce
We maintain a listing of proposed projects. Projects can be proposed by anyone in the Inkscape AUTHORS file. 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. 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'.
Meanwhile, we run official fundraisers, that have the goal of getting donations for these jobs. Each of these has a named person serving as that fundraiser's coordinator who handles all administrative manners for the duration of the campaign. It is up to this coordinator's discretion how to distribute the raised money at the completion of the fundraiser, however: a) all funds must be directed only to jobs in the list, and b) no single job can receive more than 25% of the raised funds.
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 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.
Open Questions:
Should fundraiser coordinators get remuneration of some sort, or is the ability to direct the funds they raise a sufficient reward?
Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
Should jobs 'expire' after some period of time, with any allocated funds being freed up for other jobs and/or returned to the general fund?
How do we prune out jobs that become irrelevant?
What if someone (or multiple someones) handles the job without signing up for it?
On Fri, Dec 13, 2013 at 11:40:18PM +0100, Krzysztof Kosiński wrote:
Hello all
Chiming in with a slight delay. It would be awesome if we could get that funding.
If we want to use the money to fund people working on specific features or maintenance tasks, I could help outline the goals for that, and probably also do some of the tasks myself if I have the time.
If RedHat were to provide recurring contributions, we could set up a program where performing a well defined coding task in a specified time limit is rewarded with money. The crucial difference between this and GSoC would be that we could use our program to pay people doing boring maintenance tasks such as removing deprecated functions and writing better documentation.
When it comes to rules, I would imagine something like this: Any existing committer could sign up to do one of the tasks, and the clock would start ticking. During the specified time limit, no one else can sign up to do the same task. When the time runs out and the task is not completed, the committer who signed up doesn't receive the reward and can't attempt the same task again for e.g. one year.
Regards, Krzysztof
2013/12/10 Tavmjong Bah tavmjong@free.fr:
On Mon, 2013-12-09 at 14:38 -0500, Martin Owens wrote:
Hey Guys,
More discussion with Máirín (mo) at RedHat. See below.
On Mon, 2013-12-09 at 14:18 -0500, Máirín Duffy wrote:
Okay, and are you guys going to be paying someone to develop the features you're looking at? Are you doing it through a program or as a one-off kind of thing?
I think this is something the board should talk about. I know it entirely depends on the amount of funds and the scale of participation. But it might be worth having a couple of levels of 'we wish we could do this if we had this amount of funding'
And should it be a program? The Inkscape-Equivalence program. Donate the same amount per year as you would pay for Illustrator to help the inkscape project development.?
I like the idea of the "Inkscape-Equivalence' program. I think we should make it a permanent program. Do other groups do this?
Tav
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Inkscape-board mailing list Inkscape-board@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-board
We received a request for a consultant to do some bugfixing on inkscape/inkview. I'm following up with him to learn the details, and will work with him to find a developer to consult on the work.
https://answers.launchpad.net/inkscape/+question/241781
Back to the topic of the proposal for fundraising and funded development, I'd like to get a bit more feedback from folks, particularly the rest of the board - any other suggestions or changes I should incorporate? Are people generally thumbs up or thumbs down or undecided?
On Fri, Dec 20, 2013 at 04:56:37PM -0800, Bryce Harrington wrote:
[Forwarding thread to the board mailing list. Dropping CC of board members since they're already on the list alias.]
We've talked about fundraisers and funded development in the past. For me the sticking point is always, "Who's going to handle running the fundraiser, and then judging whether the work was adequately done?"
So, I did a bit of brainstorming using Krzysztof's task rule as a starting point, tacking on the thoughts I mentioned earlier, and fleshing out how the fundraising and administration end of things could be done.
My goal here is to get us to a point where the board doesn't have to be intimately involved in specific jobs and fundraisers, but can just sign off on an official policy for how they should be handled in general, and then let the work happen organically.
Please read this over and throw darts. I have several questions that I'd want to see answers for before putting this up for a vote, so do please chime in with your opinions and thoughts.
Bryce
We maintain a listing of proposed projects. Projects can be proposed by anyone in the Inkscape AUTHORS file. 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. 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'.
Meanwhile, we run official fundraisers, that have the goal of getting donations for these jobs. Each of these has a named person serving as that fundraiser's coordinator who handles all administrative manners for the duration of the campaign. It is up to this coordinator's discretion how to distribute the raised money at the completion of the fundraiser, however: a) all funds must be directed only to jobs in the list, and b) no single job can receive more than 25% of the raised funds.
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 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.
Open Questions:
Should fundraiser coordinators get remuneration of some sort, or is the ability to direct the funds they raise a sufficient reward?
Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
Should jobs 'expire' after some period of time, with any allocated funds being freed up for other jobs and/or returned to the general fund?
How do we prune out jobs that become irrelevant?
What if someone (or multiple someones) handles the job without signing up for it?
On Fri, Dec 13, 2013 at 11:40:18PM +0100, Krzysztof Kosiński wrote:
Hello all
Chiming in with a slight delay. It would be awesome if we could get that funding.
If we want to use the money to fund people working on specific features or maintenance tasks, I could help outline the goals for that, and probably also do some of the tasks myself if I have the time.
If RedHat were to provide recurring contributions, we could set up a program where performing a well defined coding task in a specified time limit is rewarded with money. The crucial difference between this and GSoC would be that we could use our program to pay people doing boring maintenance tasks such as removing deprecated functions and writing better documentation.
When it comes to rules, I would imagine something like this: Any existing committer could sign up to do one of the tasks, and the clock would start ticking. During the specified time limit, no one else can sign up to do the same task. When the time runs out and the task is not completed, the committer who signed up doesn't receive the reward and can't attempt the same task again for e.g. one year.
Regards, Krzysztof
2013/12/10 Tavmjong Bah <tavmjong@...47...>:
On Mon, 2013-12-09 at 14:38 -0500, Martin Owens wrote:
Hey Guys,
More discussion with Máirín (mo) at RedHat. See below.
On Mon, 2013-12-09 at 14:18 -0500, Máirín Duffy wrote:
Okay, and are you guys going to be paying someone to develop the features you're looking at? Are you doing it through a program or as a one-off kind of thing?
I think this is something the board should talk about. I know it entirely depends on the amount of funds and the scale of participation. But it might be worth having a couple of levels of 'we wish we could do this if we had this amount of funding'
And should it be a program? The Inkscape-Equivalence program. Donate the same amount per year as you would pay for Illustrator to help the inkscape project development.?
I like the idea of the "Inkscape-Equivalence' program. I think we should make it a permanent program. Do other groups do this?
Tav
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Inkscape-board mailing list Inkscape-board@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-board
On Tue, 2014-01-07 at 15:13 -0800, Bryce Harrington wrote:
Back to the topic of the proposal for fundraising and funded development, I'd like to get a bit more feedback from folks, particularly the rest of the board - any other suggestions or changes I should incorporate? Are people generally thumbs up or thumbs down or undecided?
Two thumbs up. Resources can help make certain things easier so long as they're transparent and managed well.
Martin,
Thumbs up.
On Tue, Jan 7, 2014 at 3:25 PM, Martin Owens <doctormo@...23...> wrote:
On Tue, 2014-01-07 at 15:13 -0800, Bryce Harrington wrote:
Back to the topic of the proposal for fundraising and funded development, I'd like to get a bit more feedback from folks, particularly the rest of the board - any other suggestions or changes I should incorporate? Are people generally thumbs up or thumbs down or undecided?
Two thumbs up. Resources can help make certain things easier so long as they're transparent and managed well.
Martin,
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Inkscape-board mailing list Inkscape-board@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-board
Generally thumbs up.
On 8-1-2014 1:38, Josh Andler wrote:
Thumbs up.
On Tue, Jan 7, 2014 at 3:25 PM, Martin Owens <doctormo@...23...> wrote:
On Tue, 2014-01-07 at 15:13 -0800, Bryce Harrington wrote:
Back to the topic of the proposal for fundraising and funded development, I'd like to get a bit more feedback from folks, particularly the rest of the board - any other suggestions or changes I should incorporate? Are people generally thumbs up or thumbs down or undecided?
Two thumbs up. Resources can help make certain things easier so long as they're transparent and managed well.
Thanks everyone for the feedback. I think I got everyone's thoughts integrated into this updated version.
I'm posting for another round of reviews. I think we're pretty close now, so if there's no further changes suggested I'll put it up for a vote maybe next week.
Bryce
Changes: * 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. Project Proposals ===================== 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'.
2. Fundraising =============== Meanwhile, we run official fundraisers, that have the goal of getting donations for these jobs. Each of these has a named person serving as that fundraiser's coordinator who handles all administrative manners for the duration of the campaign. It is up to this coordinator's discretion how to distribute the raised money at the completion of the fundraiser, however: a) all funds must be directed only to jobs in the list, b) no single job can receive more than 25% of the raised funds, and c) 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).
3. Fundable Jobs ================= 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 Reviewer is the Fundraiser Coordinator; 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).
The Reviewer checks that the review criteria have been met.
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 30 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 board; 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.
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.
Open Questions: * How to do conflict resolution if there are problems or disagreements?
* What happens if one person signs up for the job, and someone else independently does the work?
Open Questions:
* Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
* Should jobs 'expire' after some period of time, with any allocated funds being freed up for other jobs and/or returned to the general fund?
* How do we prune out jobs that become irrelevant?
* What if someone (or multiple someones) handles the job without signing up for it?
Notes -----
Anti-Bounty ----------- A related but lesser-known type of payment is the anti-bounty, in which developers seek sponsors for work they want to do. According to Boris Mann of Bryght, who has completed at least one successful anti-bounty within the Drupal community, anti-bounties avoid many of the problems of normal bounties. Because they are posted by developers, Mann says, anti-bounties tend to be more realistic about scope, requirements, and costs. More importantly, because a developer is already interested in a project for which he posts an anti-bounty, Mann suggests that payment is less likely to destroy motivation or morale within a project, and more likely to result in a higher rate of completion than ordinary bounties. However, the concept does not appear widespread enough to draw definite conclusions from.
Developers post descriptions of projects to be done and payment desired. Sponsors can then select to contribute some or all of the funds to do the work.
Payment In Kind --------------- Developers post "wishlists" of things they'd like to receive - like computer equipment, books, travel expenses, etc. Links are included to appropriate stores to make payment easy.
Grants and Employment --------------------- Employers like redhat, etc. can directly hire, contract, or give grants to specific community members.
Fundraising Ideas ----------------- Forget all the traditional OSS project junk like cafepress, etc.
How about...
Inkscape Honey - from my Dad's bees, in ink jars
Pants. Everyone sells shirts, hats and underware. You can't go around in just shirts and underware.
Inkscape mouse and tablet
Thank you cards
Screwdriver
Pen and pencil set
VOIP hardware
GPS devices
Earrings
Thanks Bryce,
This is an excellent policy document and it's got me quite excited :-)
One thing to note about the acceptance criteria, we'll likely be asking for a more rigorous documentation, test suite writing and other meta tasks as part of a 'job'; we should make sure that is clear up front so the time-costs of those jobs can be factored in.
Open Questions:
Two open questions sections?
- How to do conflict resolution if there are problems or disagreements?
The board is the ultimate arbiter, but a first stage might be a meeting of the fund-raiser, the job specifier and the developer with maybe one other neutral developer. IRC or mailing list.
- What happens if one person signs up for the job, and someone else independently does the work?
If no one gets the money, then the doer has effectively removed an opportunity from the signer. If the money goes to the doer, then the signer had no real reason to sign up at all and not only looses the opportunity but is probably a bit sore about it too. If the money goes to the signer, then she gets to walk away without doing any work.
Subject to the board or fund-raiser being involved. I'd say put 70% to the signer (they did everything right in process) and 30% to the general fund. The signer still get the majority of what they had planned, but not everything either. Nothing for the doer though, that would be wrong every way I look at it.
Open Questions:
- Should that person get some form of remuneration too?
Yes, but, there will be a pressure to pass jobs to claim such a reward. Maybe pay them whether they pass or fail the review and focus on the quality of the work.
Fundraising Ideas
Forget all the traditional OSS project junk like cafepress, etc.
How about... things that inkscape can make or related to glory:
* Warm fuzzy feeling that the next version of inkscape will arrive. (tip amount) * Sponsored name in a commit (low amount) * Roll call on the website for this version (med amount) * Reasonable sized logo in the inkscape > About > Sponsors page (large amount) * Get to pick the nickname for the next release (large amount)
* Actual posters designed by artists who use inkscape and want to give back, signed by the rock-star developers ;-) * Inkscape branded 3D printed wacom tablet pens (impossible?)
Martin,
On Sun, Jan 12, 2014 at 03:30:08AM -0500, Martin Owens wrote:
Thanks Bryce,
This is an excellent policy document and it's got me quite excited :-)
One thing to note about the acceptance criteria, we'll likely be asking for a more rigorous documentation, test suite writing and other meta tasks as part of a 'job'; we should make sure that is clear up front so the time-costs of those jobs can be factored in.
Open Questions:
Two open questions sections?
Bad editing! Consider only the first section. The second section were all items I believe I incorporated. Sorry for the mess.
- How to do conflict resolution if there are problems or disagreements?
The board is the ultimate arbiter, but a first stage might be a meeting of the fund-raiser, the job specifier and the developer with maybe one other neutral developer. IRC or mailing list.
Thanks, I'll use that. How's this sound:
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.
- What happens if one person signs up for the job, and someone else independently does the work?
If no one gets the money, then the doer has effectively removed an opportunity from the signer. If the money goes to the doer, then the signer had no real reason to sign up at all and not only looses the opportunity but is probably a bit sore about it too. If the money goes to the signer, then she gets to walk away without doing any work.
Subject to the board or fund-raiser being involved. I'd say put 70% to the signer (they did everything right in process) and 30% to the general fund. The signer still get the majority of what they had planned, but not everything either. Nothing for the doer though, that would be wrong every way I look at it.
Interesting, and not a bad approach. What do others think?
I've tentatively added the following to section 4 (Completion Criteria):
"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."
Open Questions:
- Should that person get some form of remuneration too?
Yes, but, there will be a pressure to pass jobs to claim such a reward. Maybe pay them whether they pass or fail the review and focus on the quality of the work.
For now, as per other feedback, I've opted to omit remuneration for the fundraiser and reviewer. If we find someday that these roles are insufficiently motivated and bottleneck progress, we can re-evaluate.
Fundraising Ideas
Forget all the traditional OSS project junk like cafepress, etc.
Honestly I think this section was intended to be just my own personal notes and ideas, but if anything was inspirational or useful, great. So it's my mistake this was included in the mailing; actually I think brainstorming for fundraising should probably be kept separate.
How about... things that inkscape can make or related to glory:
- Warm fuzzy feeling that the next version of inkscape will arrive.
(tip amount)
- Sponsored name in a commit (low amount)
- Roll call on the website for this version (med amount)
- Reasonable sized logo in the inkscape > About > Sponsors page (large
amount)
Get to pick the nickname for the next release (large amount)
Actual posters designed by artists who use inkscape and want to give
back, signed by the rock-star developers ;-)
- Inkscape branded 3D printed wacom tablet pens (impossible?)
Very interesting ideas! But I do think we should probably keep these separate from this proposal regarding the underlying mechanics.
Bryce
participants (7)
-
Bryce Harrington -
Bryce W. Harrington -
Johan Engelen -
Josh Andler -
Martin Owens -
Tavmjong Bah -
Ted Gould