Inkscape Board of Directors
March 2014
inkscape-board@lists.inkscape.org
- 6 participants
- 3 discussions
[REFERENDUM] LGM Attendance 2014
by Bryce Harrington
The board is requested to vote on the following matter:
Proposal:
[ ] a. Cover travel and hotel expenses for up to 5 Inkscape
developers to participate in LGM 2014, maximum of $500
per developer.
[ ] b. Do not cover expenses for Inkscape developers to attend LGM.
Background:
LGM is an important meeting for the Libre graphics movement. This is
a good place to showcase our upcoming release, Inkscape 0.91. Having
Inkscape developers get together is always a good thing. Having
Inkscape developers talking with others in the Libre Graphics
movement might even be better.
Unfortunately, it is probably too late to have a developer propose to
give a talk on Inkscape at the meeting.
-- Tavmjong Bah
"Developer" is defined as someone listed in Inkscape's AUTHORS file as
of Feb 19, 2013. -- Bryce Harrington
9 years, 3 months
- 6
- 10
[RFC] [UPDATED v.3] Proposal for fundraising and funded development process
by Bryce Harrington
Posting for one more review before we vote.
Please (please!) take an hour or two to study this over and give
feedback. This is going to be a big change for Inkscape (hopefully!)
and I want to make sure we're doing it in a way that it'll work well.
Think of it from the perspective of someone running a fund raiser,
someone proposing a project to be worked on, and someone who'll be doing
the work.
Is this too much? Too little? Does it motivate you to hit the streets
to drum up money, or make you want to tear your eyes? Ask the rules
lawyer in you to see if there's any ways to abuse it. Call forth the
grammar nazi in you while you're at it.
[Tony: I've incorporated changes that I hope address all the points you
raised, but I'm not 100% confident that I was successful, as some of the
concerns were sort of non-specific. Please re-review especially the
limitation on Reviewer to contributing 50% or less of the funds; 50% is
a WAG - tell me if it should be 0%, 10%, or what.]
Barring any major issues, I hope to get changes incorporated and this
back out for voting within a couple weeks.
Bryce
Changes v3:
* Reordered sections for clarity. Start with fundraising.
* Discuss the duties of Fundraiser Coordinators in more detail.
* Reviewers cannot have contributed more than 50% of the funds for the
project. This is due to IRS restrictions we must follow in order to
remain covered as non-profit. "50%" is just a WAG and may need
adjusted down (possibly to 0%) pending legal advice from SFC.
* Expire unassigned jobs after 24 months rather than 30.
* Note that SFC can be used for resolving conflicts of interest.
Changes v2:
* Added subheadings
* Added Exception section clarifying board powers
* Jobs expire after 30 months
* Gave original proposer power to modify or terminate projects
* Defined the Reviewer role
* Added example Delivery and Acceptance Criteria as an appendix
------------------------------------------------------------------------
Inkscape Funded Development Model
---------------------------------
1. Fundraising
===============
Using the model we'll describe below, anyone may start an official
fundraiser for Inkscape development. We leave it to your imagination
how to structure and run your campaign, so long as a few requirements
are met.
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.
They have three duties:
a) Administration of the fundraiser
b) Allocate raised funds to projects
c) (Optionally) Be involved in final signoff of completed projects
The first duty is left to the Fundraiser Coordinator's discretion.
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.
For ongoing fundraisers, the coordinator responsible for setting it up
can specify the distribution programmatically (e.g. "distribute evenly
to the four oldest jobs in the list", or "10% each to each to the ten
jobs with the highest funding", or "allocated evenly across all
documentation jobs". 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).
The third duty - signing off on completion of the project - is described
in more detail below. The Fundraiser Coordinator *can't* do this if
they personally contribute most of the funding, because it'd run us
afoul of IRS rules.
2. 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.
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'.
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
of each donation. All donations are tax deductable. We maintain a list
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.
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.
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.
5. 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.
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.
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.
The Board may also make changes to this policy via a normal majority
vote.
7. 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, Fundraisers, Reviewer, or Inkscape Board
Member). For proper quorum, the Meeting must be attended by the
Developer, the Project Proposer, the Reviewer, at least one Fundraiser,
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.
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.
9 years, 6 months
- 3
- 5
- ← Newer
- 1
- Older →