[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
8 years, 9 months
[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
Re: [Inkscape-board] [RFC] [UPDATED v.3] Proposal for fundraising and funded development process
by Bryce Harrington
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
9 years
[REFERENDUM] Should Inkscape Join the Open Invention Network?
by Bryce Harrington
Proposal:
[ ] a. Join the Open Invention Network (OIN). Pledge that the
Inkscape organization would never use patents aggressively
against the Linux System.
[ ] b. Remain independent from the Open Invention Network.
Background:
Hi Bryce,
My name is Valer and I am writing to you on behalf of the Open Invention
Network (OIN). Our mission is to support projects developing or using
Linux-related and open source technology by deterring patent aggression.
We do this through a community that pledges not to assert patents
against each other over the Linux System technology. This pledge covers
over 2,100 Open Source packages. It is structured to reduce risk on core
operating system and middleware technologies. Almost 750 projects and
companies from all areas of technology creation, deployment and use have
joined our community so far (see not very up to date list:
http://www.openinventionnetwork.com/licensees.php)
We want to invite Inkscape to our community.
You may be interested in our community credentials and to get some more
context about our work. Here is an endorsement from Eben Moglen,
Chairman of the Software Freedom Law Center:
http://emoglen.law.columbia.edu/now/organizations/OIN
Here is an endorsement from Jim Zemlin, Executive Director of the Linux
Foundation:
http://www.linux-foundation.org/weblogs/jzemlin/2009/09/09/protecting-lin...
Our community is free to join. The only thing we want is a pledge that
Inkscape would never use patents aggressively against the Linux
System. Of course it never will, and that's a symbolic gesture, but it
remains very important for our work. When we also bind big companies
with this pledge we are sure they will not attack ç in this context for
example. But their participation in OIN is also very important in
various other aspects.
And these companies are numerous. For example Valve Software and Dropbox
are on of the latest bigger companies joined in. UnitedStack from China
joined just a weeks hours before. Pretty much everyone else is in there
too, from Red Hat to GNOME, Fujitsu to CentOS, Google to KDE to
OpenStack Foundation. This is the largest community to address software
patent challenges in the world. The idea is: when everybody pledges
freedom, there will be no wars.
We are passionate supporters of the Linux System and open innovation. I
hope we can work together by welcoming Inkscape to our non-aggression
community. Every single voice helps us face current market challenges
while investing in a more collaborative future.
Attached is a very short overview of OIN + FAQs, but I am happy to
answer any questions and to explain in more detail why the pledge of
Linux System and open source patent non-aggression is so important for
open innovation.
May you decide positively there is a possibility to sign online:
http://licenses.openinventionnetwork.com
Please consult to Johan, Tavmjong, Ted and Josh and let me know what you
guys think.
Regards,
Valer Mischenko,
Open Invention Network
www.openinventionnetwork.com
Votes:
Josh Andler ?
Ted Gould ?
Johan Engelen ?
Bryce Harrington ?
Jon Cruz ?
Mental Guy ?
Tavmjong Bah ?
Resolved:
TBD
9 years
[REFERENDUM] Move inkscape-board mailing list from SourceForge to Launchpad
by Bryce Harrington
A majority vote of the current board members is required for this
matter.
Proposal:
Move the email list for the Inkscape Board of Directors from
SourceForge to Launchpad.
[ ] a. Yes, move inkscape-board@ to Launchpad
[ ] b. No, keep list on SourceForge
Regardless of this vote, all other mailing lists will remain
unchanged.
Background:
All Inkscape mailing lists are currently hosted from SourceForge, for
historical reasons. When Inkscape was founded we used SourceForge for
all source control, bug tracking, mailing lists, etc.
Since that time we've moved off SourceForge to Launchpad for the first
two items, but not the last.
The mailing list archives are important for board matters both to locate
past decisions, and for facilitating general transparency into our work.
Both SourceForge and Launchpad have their own web interface for viewing
list archives, but SourceForge's implementation is clunky and limited
compared with Launchpad's.
Launchpad also provides a more integrated way of managing your mailing
list subscriptions compared with SourceForge.
Mailing lists hosted at SourceForge have a textual advertisement
appended to them, whereas Launchpad does not. This is minor, but it
does result in our archived emails looking more tidy and professional.
Another benefit of moving is that the board would be able to handle all
list administration. Currently, the SourceForge admin team does list
administration. Presently this is a trivially small benefit, since we
tend not to require any administration work, and since several board
members are also SourceForge team administrators.
A limitation of Launchpad is that it permits only a single mailing list
per team. However, for the board this is not a hinderance since we only
have a single mailing list. If a second list is needed, we can always
just establish a subteam.
9 years
Re: [Inkscape-board] Fwd: How is Inkscape funded (or is it)?
by Bryce Harrington
On Thu, Jan 30, 2014 at 12:15:48PM +0000, Paul Suckling wrote:
> Dear Bryce.
>
> A couple of months ago I contacted you about potentially donating to
> Inkscape (via sourceforge with the username poruko). You will no
> doubt be pleased to hear that my company decided to donate approx.
> 100 GBP to the Inkscape project via the Software Freedom
> Conservancy. (The payment had to go via US dollars, so the actual
> amount you end up with could vary slightly from that.) The donation
> will appear as originating from Elizabeth Cairns at our company,
> Quintessa Limited.
>
> All the best,
>
> Paul
Excellent, thanks Paul!
To give you some visibility into where we're allocating funds, the board
has recently selected the following:
1. Purchase of various programming manuals for the top 10
contributors in 2013. The books just shipped last week.
2. Sponsorship of one of our developers to attend the SVG working
group meeting in Leipzig, to cover travel, hotel, and meal costs.
3. Sponsorship of 6 developers to attend the LibreGraphics Meeting
(LGM) also in Leipzig, covering up to $500 of expenses each.
Thanks again for your generous support.
Bryce
9 years, 1 month
[REFERENDUM] Funding for Tav to attend LGM and Leipzig SVG WG meeting
by Bryce Harrington
The board is requested to vote on the following matter:
Proposal:
[ ] a. Approve funding Tav to attend LGM and the Leipzig SVG WG meeting
as outlined below.
[ ] b. Do not approve funding Tav.
Voting:
This is a majority vote with Tav recused. Four votes for either
(a) or (b) are required to achieve a decision.
If a tie vote is reached, or if four votes are not achieved within a
week's time, we'll have Tav select someone from the AUTHORS file to
vote in his place.
Background:
I (Tav) would like funding to attend the Leipzig SVG working group
meeting, held April 7-10 (after LGM April 2-5, 2014).
Here, I am asking for funding to attend both LGM and the Leipzig SVG
meeting. (Note there is also another SVG meeting held in Winchester in
August, but I will submit a separate funding request for that later;
potentially I may get some funding from the conference organizer.)
This is a critical time for SVG 2. The new features I am responsible
for include mesh gradients, hatched fills, and auto-flowed text. The
move to "CSS based" text layout which brings in auto-flowed text (with
a natural SVG 1.1 fallback) requires a lot of work which is easiest to
do face-to-face. Critical decisions are made at these meetings
(i.e. dropping SVG fonts). It is important to have Inkscape interests
represented.
The Leipzig meeting is being held in conjunction with LGM. I will be
giving a talk on SVG at LGM. I may receive some travel support from
the LGM organizers but it is not sure at the moment, so I have included
transportation costs.
Approximate costs for Leipzig,
10 nights lodging/meals $1000
Transportation $400
A report from the Tokyo WG meeting can be found at:
http://tavmjong.free.fr/blog/?p=979
Tavmjong Bah
9 years, 1 month
Upcoming votes
by Bryce Harrington
Hi all,
We've got several proposals in various states of discussion, which I
think would be good to bring to a vote over the coming month.
In general do you guys prefer having a bunch of different things to vote
on in one go, or to have them spaced out time-wise to permit
deliberation?
Here's the topics I'm thinking we should vote on:
a. 2013 Developer Education Book Campaign
b. Funded Development Procedure
c. Job Exceptions for Priority Projects
d. Move Inkscape Board mailing list from SourceForge to Launchpad
Anything else that'll need votes?
Bryce
9 years, 1 month
[RESULTS] Developer Education Book Campaign 2013
by Bryce Harrington
Here is the breakdown for the voting on this issue:
Josh Andler Yes
Tavmjong Bah unknown
Ted Gould Yes
Bryce Harrington Yes
Johan Engelen Yes
Tim Cole unknown
Jon Cruz unknown
With 4 yes votes we have a majority decision.
Johan, please go ahead and proceed with step #3. Once that's done, I'll
follow up with step #4.
Bryce
----- Forwarded message from Johan Engelen <jbc.engelen@...31...> -----
Date: Wed, 15 Jan 2014 17:59:50 +0100
From: Johan Engelen <jbc.engelen@...31...>
To: Bryce Harrington <bryce@...2...>
Subject: Re: [Inkscape-board] [REFERENDUM] Developer Education Book Campaign 2013
Hi Bruce,
I thought I had already re-voted, sorry.
I vote a. Yes
Cheers,
Johan
----- Reply message -----
From: "Bryce Harrington" <bryce@...2...>
To: "Johan Engelen" <j.b.c.engelen@...51...>
Subject: [Inkscape-board] [REFERENDUM] Developer Education Book Campaign 2013
Date: Wed, Jan 15, 2014 02:43
Btw, I need you to officially re-vote for the update so it's on record.
Bryce
On Mon, Jan 13, 2014 at 06:29:20PM +0100, Johan Engelen wrote:
> a. YES
>
> - Johan
>
>
> On 13-1-2014 9:46, Bryce Harrington wrote:
> > A majority Board vote is required for the following proposal.
> >
> >
> > Proposal:
> >
> > 1. Purchase and distribute a programming book to the top 10 Inkscape
> > contributors for the past 12 months, as calculated by Ohloh.net:
> > http://www.ohloh.net/p/inkscape/contributors?query=&sort=commits_12_mo
> >
> > 2. The contributors can choose from one of the following books:
> > a) Effective C++, 3rd Ed.
> > by Scott Meyers
> > b) Refactoring: Improving the Design of Existing Code
> > by Martin Fowler
> > c) A Tour of C++
> > by Bjarne Stroustrup
> >
> > 3. The campaign proposer (Johan Engelen, or their designee) will be
> > empowered to officially announce and introduce the campaign to the
> > larger community.
> >
> > 4. The board chairperson (or their designee) will be empowered to
> > i) Identify the qualified contributors as per (1), ii) Contact the
> > qualified book recipients to collect their address and choice of book
> > from (2), iii) Purchase and disseminiate the books to the provided
> > addresses, iv) Collect reimbursement from SFC for expenses incurred.
> >
> >
> > [ ] a. Yes, conduct this campaign as defined above
> > [ ] b. No, we should not conduct this campaign
> > [ ] c. Maybe, but I disagree with some definition of the campaign
> >
> >
> > Background:
> >
> > """
> > Lately, I've become obsessed with code quality. I've been reading
> > Bjourne Stroustrup's "bible" on C++11, watched all videos of the
> > "Going Native" conferences, started using clang, ..., and it has made
> > me much more aware of the language's facilities for preventing bugs. I
> > regularly browse over Inkscape's code and try to fix things I think
> > can be improved (janitorial); our source is a pretty big mess
> > I really do think Inkscape can use some love to improve logic and to
> > decrease some amount of spaghetti.
> >
> > I just saw the book "Effective C++", which I believe is a great resource
> > to inspire thought and learn how to write better code, and is meant for
> > experienced programmers. In general: how do you guys feel about
> > donating something [like this book] to our top committers for their
> > "education"? We would need some metric of what "top committers" means,
> > we could use ohloh.net's numbers.
> >
> > *For example*, we have 10 people that committed more than 50 times in
> > the past 12 months. So that'd be 10 books = 10 x 31 euro = 310 euro
> > cost --- shipping and whatnot --> 400 euro cost.
> >
> > (After we release 0.91, I will become very active in pushing for C++11
> > (i.e., upgrading our compiler dependencies to more modern versions so
> > we can start using part of C++11 features), and general maintenance /
> > refactoring / cleaning up. It's pretty rewarding I find, and very
> > low-key in terms of long-time brain-investment.)
> >
> > Johan
> > """
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > Critical Workloads, Development Environments & Everything In Between.
> > Get a Quote or Start a Free Trial Today.
> > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Inkscape-board mailing list
> > Inkscape-board(a)lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/inkscape-board
> >
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Inkscape-board mailing list
> Inkscape-board(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-board
----- End forwarded message -----
9 years, 1 month
Re: [Inkscape-board] new Inkscape website (was: Re: updating DNS info for Inkscape: OSU-OSL needed)
by Bryce Harrington
On Mon, Dec 09, 2013 at 10:49:46AM -0500, Tony Sebro wrote:
> On 12/06/2013 07:05 PM, Bryce W. Harrington wrote:
> >Thanks; I worked through OSUOSL to get the DNS changeover done. The new
> >website is live.
> >
> ...and looks great, by the way. Kudos. :) And, thanks for taking
> care of the Google Checkout request.
>
> Now that the new site is up, please let me know when you've had a
> chance to create a page for the trademark policy. Thanks!
I went ahead and created a page for this.
http://inkscape.org/en/about/trademark-policy/
When we have more policies posted we might move this elsewhere in the
site, but this will do for now.
Btw, I also set up a page listing board members, although Jon and Mental
don't have accounts yet so it's only partial. It would be good for
everyone to add a short bio, 2-3 sentences about themselves.
http://inkscape.org/en/about/board-members/
Bryce
9 years, 1 month