On 27-3-2014 2:24, Bryce Harrington wrote:
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.
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 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.
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 issues.
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 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, 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.
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 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.
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.
-Johan