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