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 allocated
> >to projects in the official Jobs List, with no more than 25% of the
> >total raised funds going to any one project. No guarantee is made that
> >the project will be undertaken if there is insufficient developer
> >interest.
> 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
them...
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
> "Conservancy." Thanks!
Incorporated.
> >of each donation. All donations are tax deductable. We maintain a list
> 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."
Incorporated
> >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.
> 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
> >>chance.
> 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
> bandwidth.
>
> 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
> deliverable.
>
> 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.
Incorporated.
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, 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.
> 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
people.
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
> >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.
> 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!
Bryce
