On Tue, Feb 25, 2014 at 03:16:02PM -0500, Tony Sebro wrote: 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. Incorporated. All instances of "Fundraiser" removed and replaced with the more specific terms. 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. """ 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. Incorporated. Incorporated 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. """ 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. """ 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. 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