On Tue, Feb 25, 2014 at 03:16:02PM -0500, Tony Sebro wrote:
On 02/24/2014 02:14 AM, Bryce Harrington wrote:
>Posting for one more review before we vote.
I've added my comments inline below.
Thanks again Tony.
tldr summary: I incorporated all your suggestions. I addressed some of
the questions you raised but there's nothing requiring further feedback
from you (although more feedback would be quite welcome). I will do a
v.4 update after I've gotten feedback from more folks.
>First, the person who organizes and supervises a fundraising campaign is
>termed a Fundraiser Coordinator. We may have multiple coordinators if
>we have multiple campaigns, but only one coordinator per fundraiser.
"Fundraiser" is an ambiguous word here, in that it could be read to
refer to the coordinator or to the campaign. I recommend just using
"fundraising campaign" or "campaign" to refer to the activity
designed to solicit donations, and "coordinator" to refer to the
person supervising the activity.
Incorporated. All instances of "Fundraiser" removed and replaced with
the more specific terms.
>The second duty should be straightforward. All funds must be
>to projects in the official Jobs List, with no more than 25% of the
>total raised funds going to any one project. No guarantee is made that
>the project will be undertaken if there is insufficient developer
So, campaigns aren't explicitly tied to specific projects on the
Jobs List, then? That's a viable strategy with pros and cons: on
the one hand, you'll make sure that at least some funds get routed
towards dull-but-needed projects on the Job List. On the other
hand, you may lose some contributors who are only willing to donate
if their funds are allocated for their specific pet projects.
Incorporated. Several people now have pointed out that the 'spread the
wealth' requirement feels odd. I'll go ahead and drop it.
I do worry that those dull-but-needed projects are going to get left
fundless, but I suppose if and when that becomes an actual problem, at
that point we can look into changing the rules to fix it.
Another worry is that all-for-one-project type fundraisers may end up
overpaying for the popular projects. But I suppose that's a type of
problem we'd *like* to have...
Perhaps we can just encourage these behaviors rather than require
Here's the new text:
The second duty should be straightforward. When the fundraiser is
completed, all funds must be allocated to one or more projects in the
official Jobs List. No guarantee is made that any given project will be
undertaken if there is insufficient developer interest, but future
fundraisers can up the funds allocated to it to stimulate interest.
We expect some campaigns will wish to target one or more specific
projects, and announce this upfront to stimulate donations. This is
fine to do, but keep in mind that projects can change (or get
implemented) while the campaign is under way. So instead of naming
specific projects, it may be better to describe the types of projects
the campaign is aiming to fund, and make the specific decision(s) when
the fundraiser is over.
However, this does beg the question: what kinds of campaigns do you
anticipate launching? Many successful FLOSS fundraising campaigns
are solely comprised of posting a specific, long-ish term project
road map on a website and soliciting funds to be allocated for that
road map. Now, that's not the only way to go, but what other kinds
of campaigns are you contemplating?
Fair enough. As I've stated I'm trying to make this general enough to
support a wide variety of types of campaigns, which ought to include
what you've described.
Generally what I've been imagining are fundraisers targeting particular
themes, such as improvement of color management, which then pick out a
handful of projects that further those goals.
I'm also imagining that we would be more successful with a set of
narrow, well-defined projects than one big project. So like "Improve
color management" may sound like a project worth backing, but it's
ambiguous as to what would actually need done to achieve it. I think
part of my reasoning for requiring no more than 25% per project is to
subtly encourage people to split up large ideas into sets of small and
specific projects. But perhaps this engineering is best left out of the
policy itself, and handled more by our implementation of it.
>3. Fundable Jobs List
>The money from these fundraisers goes to the Inkscape Foundation account
>administered by the Software Conservancy, who takes a small percentage
I saw this in a few places. To fix, just do a find/replace "the
Software Conservancy" with "Software Freedom Conservancy" or just
>of each donation. All donations are tax deductable. We maintain
As a general rule, that's true in the US. But, to be more precise,
please use this language instead, especially if this policy is to be
published on Inkscape's website: "Conservancy is a US 501(c)(3)
public charity, and all donations are tax deductible in the United
States as allowed by law."
>of allocations-to-jobs so we can keep track of what money
>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.
In my first feedback email, I noted that this clause might create
some issues. At the time, you responded with:
>>That's a good thought. I think though that we can work from the
>>assumption that everyone in the AUTHORS file is worthy of trust, and can
>>be trusted to act professionally. It can be quite hard to ascertain
>>people's qualifications, so while vetting is a good idea, it may be
>>labor intensive to do in practice; it also runs the risk of
>>inadvertantly shutting out people who'd do a good job if given the
I hear what you're saying, but I'm still worried about this. For
one: we may trust everyone to act professionally, but the policy
should allow the Inkscape Committee to respond when someone acts out
of character. For example, if an eager, well-meaning developer from
the AUTHORS list checks out 6 projects at once, then no one else can
work on them for 6 months. The developer might be qualified to
handle each project, but his/her eyes might be bigger than his/her
Besides: Inkscape has a vested interest in identifying the most
qualified developers who can make the most progress on each
job/project in the least amount of time. Now, obviously, it's hard
to find the ultimate developer in every respect: the most qualified
developer may expect a larger bounty and/or may have less bandwidth
than another qualified but less experienced developer. Still, the
best way to maintain positive relationships with donors is to
produce high quality results in a timely fashion. The first
developer to click may not be the best equipped to provide that
I suppose these concerns become far more relevant as the size and
complexity of a given job/project grows. A "first come, first
serve" system might be the most efficient way to manage a high
volume of smaller, discrete jobs, or relatively easy jobs that
require more time and effort than expertise. But, I recommend that
Inkscape take the time to vet candidates for the larger, longer, or
more complicated projects. If a job is large enough (and if you've
raised enough money to fund the work to tackle it), that individual
developers and developer shops alike might be willing to respond to
a formal RFP. Conservancy has experience helping our member
projects through the process of vetting and selecting candidates for
longer-term contracts; if you want to go down this path, let us
know. Inkscape could certainly do both, i.e., set up a Job List for
smaller/easier jobs, and create one-off campaigns with different
rules for the major jobs.
Okay, I still am very worried about the labor intensity of this (half
the reason for doing this policy is to get the board out of the vetting
business) but I defer to your judgment. Maybe as a compromise the board
can elect one of its members to delegate the review duty to?
Proposed new text:
Anyone in the Inkscape AUTHORS file is eligible to apply for a job. The
applicant must submit a Job Proposal, which will identify the
applicant's qualifications for doing the job, and outline how they
intend to do the implementation.
The Inkscape Board will delegate one of its members to review and vet
applicants to help ensure the best candidates are selected for each job.
For larger, longer, or more complicated jobs the vetting may take some
time, but for moderate sized jobs the intent is for a decision to be
made within a few days. The Inkscape Board may elect to mark some jobs
(such as smaller ones) as Pre-Approved; once the applicant files an
application they may begin the job immediately, no vetting required. No
one may assign themselves more than one Pre-Approved job at a time, and
the Board reserves the right to subsequently review the application and
disapprove it in case of problems.
>4. Completion Criteria
>The Reviewer makes the decision as to whether the job has been
>adequately completed, using the originally specified criteria.
>By default, the Fundraiser Coordinator is the Reviewer; if the project
>was funded from multiple sources, the one that allocated the largest
>amount of funding (or their chosen delegate) is the Reviewer. This
>person must formally accept the Reviewer role by email within 1 week.
>For any reason, they may opt to decline the Reviewer role. If they are
>unresponsive or opt to decline the role, it passes to the next
>Fundraising Coordinator. If no Fundraising Coordinators take or
>delegate the role, then the original Project Proposer may take the
>Reviewer role (or delegate it to a person of their choice).
>However the Reviewer is decided, the Reviewer can't have contributed
>more than 50% of the funds for the given project.
I would add "or the Reviewer's employer." Re: conflict: I'm not
too concerned about it, especially if the Reviewer isn't also the
person who submitted the Job being reviewed. If a single person
submits a Job, creates a fundraising campaign to fund completion of
that Job, and reviews the work on that Job to determine completion,
then there are more opportunities for a potential conflict of
interest. And, I'd have a few follow up questions. E.g., is this
person also trying to complete the work him/herself and be rewarded?
Does the person (or the person's employer) have an independent
business interest in seeing that job completed? Etc.
Incorporated. To keep things straightforward I've restricted
Proposer != Reviewer, which I think addresses the issue and encourages
distributing the volunteer workload. In cases where it would devolve to
the Proposer, we'll just bump it to the board to decide. Hopefully that
will be a rare situation.
Proposed new text:
By default, the Fundraising Coordinator is the Reviewer; if the project
was funded from multiple sources, the one that allocated the largest
amount of funding (or their chosen delegate) is the Reviewer. This
person must formally accept the Reviewer role by email within 1 week.
For any reason, they may opt to decline the Reviewer role. If they are
unresponsive or opt to decline the role, it passes to the next
Fundraising Coordinator. If no Fundraising Coordinators take or
delegate the role, then the Inkscape Board will delegate a Reviewer.
However the Reviewer is decided, he or she must be a different person
than the original Project Proposer, and neither the Reviewer nor the
Reviewer's employer may contribute more than 50% of the total funds for
the given project. We want to avoid a situation where a person or their
employer has an independent business interest in seeing the job
completed, and is over-involved in the management of the work.
>If someone other than the assigned Developer performs the work,
>satisfaction of the Reviewer, then the signed Developer will receive 70%
>of the funds. The remaining 30% are returned to the Inkscape general
So, if Developer A has "checked out" a job from the list, and
Developer B simply does the work and submits a patch, Developer A
still gets 70% of the funds? I agree that Developer B shouldn't get
compensated without going through the job list checkout process, but
why would Developer A be compensated for work he/she didn't do?
Yeah, this is a tricky condition. We've debated on the board list about
how to handle this.
We think Developer A should be compensated some amount. After all
they've followed the rules and should expect to be given a fair shake at
completing the project, so if Developer B does an end run around them,
it's not fair.
We don't feel Developer A deserve the full 100% of the funds, as they
didn't complete the job. There's a range of conditions that this
situation can arise: Maybe Dev A isn't making progress and Dev B steps
in to get the job done, process be-damned; maybe Dev A has done a lot of
the initial legwork, and Dev B is excited for the feature and
impatiently finishes A's work and commits it; perhaps Devs A and B have
been collaborating, and Dev A got sidetracked by Real Life matters so
Dev B took care of the final touches; maybe Dev A and Dev B are in
disagreement, and Dev B rushes their solution in early, to "win" the
argument; maybe Dev B is an asshole that wants to dick around with
If we give Developer A too little, like 25%, I think we invite debate
and get ourselves into a judge role between A and B. We risk alienating
developers or at least causing bad feelings when it's completely
unnecessary - from the donors' perspectives the original intent of the
job has been fulfilled. So we picked 70% as it seems high enough that
no one should feel "screwed" by the situation. I think it also serves
to encourage people to play by the rules.
I think we're still open to better ideas here, but 70% was what we came
up with from the above line of reasoning.
>6. Process Exceptions
>Historically, all development work funded by the Inkscape Project
>required authorization by the Inkscape Board of Directors; this funding
>model is to establish a structure for development funding that does not
>require Board involvement. However, the Board retains the ability to
>authorize exceptions for anything outside the bounds of this policy, to
>be handled on a case-by-case basis, with decisions made by a majority
>In particular, the Board may select by vote certain projects to be
>immediately fundable, without needing to wait the normal 6 month period.
>They may also withdraw any project or job at any time, by majority vote.
I'd also consider shortening the exclusivity period if the developer
is dormant: six months of inactivity will not sit well with donors.
So, for example, a Developer could have exclusive rights to a Job
for 6 months -- on the condition that he/she posts a bi-weekly or
monthly- progress report.
Incorporated. Great idea on requiring monthly progress reports.
This text added to the Fundable Jobs List section:
When an applicant is assigned the job, the clock starts ticking. The
applicant must post at least one progress report each month (e.g. to a
blog or to the Inkscape wiki). During the time limit, so long as the
monthly reports are being clearly posted, no one else can apply to do
the same job. If two months pass without a report, or when the 6 months
time runs out, and the job is not completed, the assignee doesn't
receive the funds and can't attempt the same job again for 6 months.
The job is considered completed when the identified deliverables are
delivered according to the specified criteria.
Maybe that could be worded better but hopefully it conveys the intent.
Thanks again Tony!