On Tue, Mar 25, 2014 at 11:59:26PM +0000, J.B.C. Engelen (Johan) wrote:
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.
Second, this board's charter focuses on financial matters, not technical 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 Technical Board".
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.
The alternative would be for Josh or myself or one of the other "project 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'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.
There are many alternative models in between these. For instance, allow anyone to commit changes, but only if it has received a Reviewed-by or a Tested-by at least one other person. And permit anyone to revert code that doesn't have one or the other. Or allow everyone to commit to a Working branch, but then cherrypick changes from that into the Official tree, once evidence proves them ready to go. etc.
Particularly, how can we enforce coding standards, coding style, etc.?
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.
Related to this, how strict do we want to be on inclusion of library code copies in our codebase, that have but a single maintainer or no maintainer at all?
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.
Bryce