9:56 a.m.
[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
>
>
>
>
5:01 a.m.
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
12:11 p.m.
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
6:24 p.m.
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
5:17 a.m.
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
10:05 a.m.
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
1:08 p.m.
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,
3:58 a.m.
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
9:05 a.m.
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
11:22 p.m.
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(a)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....
_______________________________________________
Inkscape-board mailing list
Inkscape-board(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-board
8:13 a.m.
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....
_______________________________________________
Inkscape-board mailing list
Inkscape-board(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-board
8:25 a.m.
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,
9:38 a.m.
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....
_______________________________________________
Inkscape-board mailing list
Inkscape-board(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-board
5:18 a.m.
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.
>
9:43 a.m.
New subject: [UPDATED] Proposal for fundraising and funded development process
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
5:30 p.m.
New subject: [UPDATED] Proposal for fundraising and funded development process
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,
6:37 p.m.
New subject: [UPDATED] Proposal for fundraising and funded development process
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
3423
days inactive
3445
days old
inkscape-board@lists.inkscape.org
16 comments
7 participants
participants (7)
-
Bryce Harrington -
Bryce W. Harrington -
Johan Engelen -
Josh Andler -
Martin Owens -
Tavmjong Bah -
Ted Gould