On Thu, Mar 27, 2014 at 06:48:18PM +0800, Jelle Mulder wrote:
Hello Bryce,
Let me give my two cents on the proposal then. In general though I applaud the plan.
Comments preceded by **
Cheers,
Jelle
Thanks for your feedback Jelle!
On Thu, 27 Mar 2014 17:00:18 +0800,
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.
** Wouldn't it be better to have some tool or method for this? Not only to prevent inconsistencies, but also to improve on the methods themselves? Granted,.. currently there probably is none, but I think it would be better to decide on some mandatory tool for project management.
Yes, it's my hope that tools will be written to simplify some of this, but I don't want to dictate much about tools in the policy. I figure initially we'll do it manually or with a spreadsheet, and go from there. If this proves popular and effective, then necessity will drive development of tools, but if no one ends up being interested, then not much use investing a lot of time into development work.
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.
** If I understand this correctly, the excess funds raised for the finished project can be diverted to other projects at the choice of the fundraiser coordinator?
Yes, so long as it's projects in the approved list, the fundraiser coordinator has the prerogative in deciding where the money will be targeted.
For ongoing fundraisers, the coordinator responsible for setting it up can specify the distribution programmatically (e.g. "distribute evenly to the four oldest projects in the list as of the end of the campaign", or "10% to each of the ten projects with the highest funding from past campaigns", or "allocated evenly across all documentation projects registered as of the start of this campaign". 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).
** If one fundraiser fails, another person can pick up the job where it left off or has to start all over again? I would suggest the latter to prevent capital being inert and just have raised capital be distributed to other projects if the set bar fails. Or do we do a refund? Maybe have 70% of the funding guaranteed towards the project it is for and 30% to cover the cost of refunds if fail and the rest to the greater goal?
Hopefully, the way this is set up, fundraisers won't fail, unless they raised $0. There is no required threshhold, so even if they raised just $5 to give to five projects, they could allocate that $5 at $1 to each project. Of course, $1 is not much of an incentive! So we'd expect someone else would follow up with a second, separate fundraiser, to raise more money to allocate to some or all of those projects.
The third duty - signing off on completion of the project - is described in more detail below. The Fundraising Coordinator *can't* do this if they personally contribute most of the funding, because it'd run us afoul of IRS rules.
** Ehm,.. that doesn't sound like too much of a challenge. Bob tells Tom it's finished, Tom signs off.
My hope is that it *isn't* a challenge. The Fundraising Coordinator has a lot of responsibilities, so I don't want to overburden anyone. But we do need a check that the project has been completed, otherwise it opens the system to abuse.
- Proposing New Projects
========================== 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.
** This should be created in a nice project management format with Ganttcharts and all I think. It will make clear how much work is expected to be done and how many people could be involved. Would be some work initially, but will make lots of things clear at the end of the project and it can be easily measured and budgeted. It will also allow for specialist to take part in multiple projects for parts of it and be rewarded accordingly.
Interesting idea! I have no idea to what degree the different project ideas will interdepend on each other though. Hopefully there'll be little interdependence, so that anyone could take any task in the list. In that case, a Gantt chart would be considerable overkill.
I think we should see how this plays out for "simple" projects first, that can be done directly with no interdependencies on other projects, and if it proves a good model, then we could look for more complex projects later.
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'.
** Wouldn't it be easier to increase funding for higher priority projects? If we combine that with the idea to use part of the funding for fun and sexy project for the tough and tedious, eventually the T&T jobs will be so valuable to fix that it's worth all the hardship and insanity.
Yes, my hope is that this happens organically. I want to avoid central planning of what we fund, and instead let this "Representative Crowdfunding" approach guide the funding decisions.
We may need to establish a feedback loop, so the developers can communicate to donors and fundraising coordinators what we feel the codebase needs (as opposed to just what's sexy and cool). I think that may happen naturally though - most likely it'll be developers defining the list of projects, and hopefully many fundraiser coordinators will be themselves developers or aware of developer priorities.
Ultimately though, my hope is to empower the donors will the ability to influence the direction of the project through their funding.
- Fundable Jobs List
====================== 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.
** Again, if the project is defined by expected tasks it may be useful to have different people work on the same project and have them share the loot. It will be common that parts will be begun by one person and finished by another.
You're probably right, and hopefully we don't prevent this from happening. Initially though, I think we should focus on one-person-per-project to keep things simple; if two or more people co-work on it then one is the lead developer and can distribute payment to her partners at her discretion.
Later if we find this model occurs more often than not, and needs more structure, then hopefully by then it'll be clearer how that structure should work.
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.
** Sound plan as there are plenty of small projects. Should the board be excluded from these projects I wonder? I actually think this shouldn't be the case as I for one would love them to earn some income for all the work they put into the projects, but there is some danger of having an interest here. Maybe some form of audit would be in place by an independent supervisor.
Oh good point. Yes to avoid conflict of interest the board should be excluded from these streamlinings. So, the can take a job that was marked pre-approved, but they'd have to get approval for it like a normal project. And of course the person vetting applicants would not be permitted to vet himself for a project.
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.
** If we are working with deadlines and milestones it will be easier to track progress and find out when things go awry.
- Completion Criteria
======================= The Reviewer makes the decision as to whether the job has been adequately completed, using the originally specified criteria.
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 assigned Developer will receive 70% of the funds. The remaining 30% are returned to the Inkscape general fund.
** This is the main reason to work with milestones. The assigned dev should be getting a percentage based on the milestones defined and reached. Those can be weighted rather than just a time percenatge as most of the hard work will be done first (like finding out how to do something), though I would like to have the bug hunting and completion task be weighted quite heavily as well as that is the more tedious and time consuming job. Maybe it should be no more than 50% for the assigned dev if he reaches the task up till the bug hunting phase milestone and it gets completed by a more proficient dev in the end phase, with 30% going to the person who finishes the project and 20% going to the general Fund.
Based on other people's feedback, I'm actually considering scrapping this section. But you've suggested a good alternative here, which is making me think that perhaps this should be moved to the Acceptance Criteria, and left to whomever writes up the project to define the milestones, payment percentages, and so on. After all, every project is going to be a bit different, and some may have more emphasis needed on bug fixing than on implementation, and others may be more the other way round.
- 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. If the Project is withdrawn, all funds allocated to it return to the general Inkscape fund.
Unassigned Jobs expire 24 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.
** Hear, hear..
- 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.
The Board may also make changes to this policy via a normal majority vote.
** It sure makes sense not to have to wait 6 months to get something on the rails.
- 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, Fundraising Campaigns, Reviewer, or Inkscape Board Member). For proper quorum, the Meeting must be attended by the Developer, the Project Proposer, the Reviewer, at least one Fundraising Coordinator, 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.
** Surely someone is bound to disagree. This can end up escalating very easily.
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.
Conflicts of interest, including conflicts with the board, are governed by the Software Freedom Conservancy's org-wide conflict of interest policy.
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.
** I would suggest a higher percentage for bug fixes as they're the tougher part of the programming. I would say a 30% for the last few lines of code and all the headaches. It will improve the whole code base if the bugs get caught and everything works to satisfaction. I would certainly add some reward for good annotation of code as well.
Okay. This bit here is just for example, but since people may derive their own plans from it, it's better to write it as close to best practices as possible.
Thanks again for the feedback Jelle! Bryce
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel