On 27-3-2014 2:24, Bryce Harrington wrote:
On Tue, Mar 25, 2014 at 11:59:26PM +0000, J.B.C. Engelen (Johan)
> Hi all,
> I'd like your opinion on how to handle developers...
> My question is, how should I/we deal with such a person, without running away
> from the project in anger.
First off, be aware the board mailing list archives are publically
visible. Thus I think discussions about specific individuals probably
is not well suited for this list.
I know. My mail was motivated by a specific individual, but the
questions were not just about that specific individual.
Second, this board's charter focuses on financial matters, not
or interpersonal, so probably this is off topic here anyway.
However, on the second point, I've been noticing a number of technical
questions come up that need decisions beyond what individual developers
can do, and wondering if it would be worth establishing an "Inkscape
I don't think this board's charter gives it the power to unilaterally
establish a technical board. So, I think to do this we'd need to have
the Inkscape developer community vote to grant us this ability. Then we
could run an election to fill such a board, and charge it with the duty
to provide Inkscape with technical decisions raised to it.
I'm not sure if we need another board for this. Maybe we do. I do think
that indeed we need a group of people with executive power for technical
The alternative would be for Josh or myself or one of the other
leads" to take a more authoritative handle on the project to drive
decisions like these. But I've never been comfortable doing that, and
frankly don't have the stamina (or time!) to fight such fights.
Either in addition or instead of a tech board, we could establish a
membership board. This would be chartered to judge and address
interpersonal problems, provide/withdraw commit rights, and other
decisions regarding who can do what in the project. They'd not be
chartered to handle any technical or financial decisions. Again, the
Inkscape Board would need to be explicitly granted the power to
establish such a board, via a general election.
I don't think we need this.
> I'm tired of confessing to people that, yes, indeed,
> Inkscape is open source and "hence" all the crashes that you experience.
I like Martin's Bake Sale analogy, and it fits well. It was indeed our
in Inkscape's original founding principles that the bar of entry be kept
very low. Many of us had been excluded from contributing to Sodipodi
for non-transparent reasons and so were sensitive to anything that could
inhibit anyone from contributing. Thus we adopted permissive,
wikipedia-style inclusiveness which stands in contrast to most other
successful FOSS projects.
There are pros and cons to this development model. The cons might be
more immediately visible than the pros! Some cons include the stress
and effort of building consensus among all developers, rather than just
having an authority make a ruling; cliques; variability in code quality;
reimplementation churn; difficult to prevent people reinventing things
for whatever random reasons. Some pros of this model are that it is
more resilient to core developer burnout (since it's easy to pull in new
developers with all rights and privs), empowers creatively unique
contributions (since developers don't have to get pre-approval or go
before a (potentially scary) review panel or whatnot before getting
stuff in trunk), and can achieve a higher development velocity since
contributions aren't gated by a review layer.
I like the open development model of Inkscape, I am not in favor of
changing it dramatically.
> Particularly, how can we enforce coding standards, coding style,
I certainly agree with the others that this looks like a job for more
tools. Are there any code style checker tools that we've used on the
Inkscape codebase before? If not, might be time to dig one up.
As I wrote earlier, good options: -Werror, clang static analyzer,
clang-format. These are tests that many people can run, and do not a
scary review panel.
They provide a very simple objective measure of what is not accepted.
(we would have to specify e.g. compiler version, but those are details
that are easily worked out)
> Related to this, how strict do we want to be on inclusion of
> copies in our codebase, that have but a single maintainer or no maintainer at
I am personally not a fan of having any library codes included in our
codebase. I understand why we do, and would not advocate getting rid of
them. But I believe packaging exists for a reason, and if done well
would remove the need to pile external codebases in.
I personally believe any codebase with no maintainer should be treated
as a contribution to the Inkscape codebase, and be required to conform
to all of our stylistic, test, and performance requirements.
What if there /is/ a maintainer?
The immediate problem is that all those libs trigger a lot of bug
warnings (many of which *are* bugs), that cloud our own bugs. A reworked
build system that allows excluding those libs for compilers warnings /
static analysis would help a lot.
Also, I think we should move all these libs to a directory called
"external" or something, so that it is clear no-one should make any
change there without committing it upstream.