Results of Community Research

[Max Kanat-Alexander]

	Okay, I'm finally getting back to these emails! :-) See my responses
inline below:

On 01/19/2010 04:38 AM, Gervase Markham wrote:
> Would it be worth instead doing some sort of three-month rolling average
> (if you've contributed in month X, or X+1, or X-1, you get a tick for
> month X)?

	I think that actually wouldn't be statistically significant, because
the freeze harm was several months long, and the recovery from it was
slow over several months, for each freeze.

> Or perhaps look at attached patches in Bugzilla as well as
> checkin data?

	Yeah, actually, I think that would be definitely worthwhile, at least
to get a sense of whether or not there was some problem with people
attaching patches but them never getting in, if nothing else.

> Did you find it was common for someone to leave the community and
> return? 

	I don't know, but them leaving the community at all is a problem, in
terms of what I was looking into. I mean, I want people to be
participating as much as they possibly can and want to.

> Is the raw data available to look at?

	Yeah, I post it up somewhere, if you think that there's something to be
gained or some other investigation of value to be done with it.

> What are the absolute numbers
> here? Was the peak community size 4, or 40?

	The peak was 25.

> Is the addition or removal
> of a single contributor a significant factor in the numbers?

	No, not really. Also, there is so much data that it's not
month-to-month that matters, but the general trend of the graph, which
is pretty clear.

> I didn't even realise there was a review-requests mailing list. Or, if I
> ever knew it, I've forgotten.

	Yeah, I didn't quite know about it either.

> - The acceptance of a patch which provides partial, useful,
> functionality in pursuit of a larger goal, rather than waiting for the
> submitter to implement the entire feature as envisaged by the team (but
> not by the submitter)

	I used to accept things like this and I no longer do, because what
happens is that we actually end up releasing for years with a
half-implemented feature that causes more problems than it solves. I
spent almost the entire 3.6 development cycle "finishing" features that
should have been complete years ago (even ones that I wrote) and the 3.8
cycle is going to be taken up with a tremendous amount of that as well.

> - The acceptance of a patch which provides useful functionality, even if
> the code would eventually be obsoleted by a rewrite of the feature which
> is wanted but un-resourced and un-scheduled

	That's something that can be accepted, *unless* the rewrite is
something that would actually only take a little more effort. For
example, component-watching is actually only a little bit easier than
everything-watching, and everything-watching might be more useful.
That's a fine line, and it's something that I know that I, at least,
could be pushed on, though, with a rational argument.

> - Within limits, the acceptance of a patch which solves a problem for an
> existing user or set of users, even if the Bugzilla team don't
> particularly like the way it's done, if the team has no plans to solve
> that problem themselves 'the better way'.

	If "the Bugzilla team doesn't like the way it's done", that means that:

	(a) The code is poorly architected
	(b) The feature is implemented in a way that we think is not helpful
enough to justify the code complexity.

	So in those cases, we won't accept patches, but we will provide review
comments and guidance on where to go with them. If the patch author
doesn't want to improve the patch, then we will probably eventually get
to it, but we won't accept a poorly-implemented feature, because that's
a disservice to our users.

> - The documentation build system was byzantine in its complexity, and
>   every time I got a new machine (or even when I didn't) it needed
>   setting up.

	That is so true. We really need to switch to xmlto, but nobody's taken
the time to do that yet. I suspect that that will resolve this issue.

> - The XML markup gave the ability to produce text, HTML and PDF, but it
>   made it very difficult to do things with graphics or layout in order
>   to make the documentation more readable. I had to remember an XML
>   vocabulary not used anywhere else in my online life.

	Yeah, I'm not an enormous fan of that process, either.

> - Documentation was treated like code, with patches having to be
>   prepared and reviewed, rather than like a wiki. Getting fixes in,
>   particularly rewrites and reorganizations, was just too much effort.

	Here's the thing about a Wiki--it requires a significant number of
editors who pay attention to it continuously and carefully. The
Win32Install instructions, which we have on the Wiki, became edited into
unusefulness while LpSolit and I weren't paying attention to them. Right
now we just don't have that many people that I think could effectively
function as technical editors of the documentation if it were on a Wiki.

	Perhaps a trade-off would be keeping the installation instructions in
Docbook, and putting everything else into the Wiki. But then how would
we do localization? Would we still be able to ship documentation with
Bugzilla? (Is that even important?)

> Have you read "The Art of Community" by Jono Bacon, recently published?
> It's fantastic on this sort of thing - well worth a read. I read it
> recently, cover to cover.

	No, I haven't. Do you think it's worth reading the whole book, or do
you think a Cliff's Notes version would help? :-)

>> 	1) Extremely rapid response to review requests. No matter how much
>> review a contributor has to go through, they usually will go through it
>> as long as there aren't LONG DELAYS between the request and the response.
> 
> Definitely. On the main Mozilla side, I've been trying for years to get
> a system in place which tracks this across the project and nags the
> appropriate people. The trick, in that case, is defining "appropriate
> people".

	I could imagine a workable system here, I think. Something like, "After
X days, remind the requestee" and then if no response, "After Y days,
remind the module owner" and then if no response, "After Z days, remind
Somebody Important." Perhaps Somebody Important could be a Community
Manager for Mozilla, or something.

>> 	Some people are hopeless programmers, and they're never going to get
>> better no matter how much you help them or how many reviews you do. For
>> these people, you don't have to imagine nice things to say about them--I
>> don't expect anybody to ever make up stuff that isn't true, just to be
>> nice. If somebody has demonstrated conclusively that they're never going
>> to get any better, or that they're just going to cause trouble one way
>> or another no matter what we do, the best thing you can do is simply
>> personally choose to ignore them, which is a personal decision that you
>> can make for yourself.
> 
> I don't actually agree with that. I think the best thing you can do is
> tell them why their contributions aren't being accepted, and say that
> unfortunately you will not be able to make time in future to review
> their contributions. This is possibly (although by no means certainly)
> more likely to result in hurt feelings than just ignoring them, but it
> is also much more likely that their life will improve as they go and do
> something they are actually good at. You certainly don't have to be rude
> or brusque when telling them, but I think you are doing them greater
> good by telling them.

	Okay, you know what, I agree with you here, that at least as a first
attempt, it's more valuable to confront the individual, if you feel like
you can. I don't think that everybody has the requisite communication
skills (or wants to do this), so if a reviewer wants me or another
person to talk to them about it instead, then we'd be happy to. But if
nobody feels capable of talking to the individual, then another option
is to simply ignore the poor contributors who aren't getting better no
matter how many times they are reminded.

> Also, bad coders might make great support people, or documenters (if
> your documentation system isn't the functional and process equivalent of
> writing code ;-).

	Yeah...I don't think I've ever seen a really poor coder write good
documentation or provide good support, though.

>> 	Look, I understand that sometimes coding and working on a collaborative
>> project with people who have different viewpoints can get REALLY
>> frustrating! I've been an offender in this area just as much as anybody
>> has been! But it's really not OK for us to insult other developers
>> personally just because we're frustrated with them personally.
> 
> I agree with all of what you write. Have you noticed any of this? This
> isn't acceptable in a more broader Mozilla context, as well as in a
> Bugzilla one, and I take it seriously when I find it.

	Well, I think that I notice it more in cases like, "That is a
stupid/ridiculous idea"--that's something that I consider a personal
attack on the individual instead of a constructive method of working
together. In general, I more often see personal insults *veiled* as
"professional disagreements" than I see actual personal insults.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.