Results of Community Research

[Gervase Markham]

On 12/02/10 22:37, Max Kanat-Alexander wrote:
>> 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.

What I meant was, if your definition of "leave" was "didn't contribute
for a month", then I'm sure I "left" and "rejoined" several times over
the last 10 years. I wanted to suggest that if you saw it was common for
people to "leave" and "rejoin", then perhaps you needed to average over
a longer time.

>> - 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.

There's a difference between "half-implemented" and "half-implemented" :-)

If something is half-implemented in the sense that "it half-does A",
then I can see what you mean, and you are right to object. But if it's
half-implemented in the sense that "it does A, but it would be great if
it did B too, because really B and A go together, and in an ideal world
Bugzilla would do both A and B", then IMO we should still take it. It's
normally things in the latter category that I object to. For example,
Myk's component watching patch was rejected in favour of fixing a
"generic watching" bug. Five years later, we have neither.

>> - 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.

Great example - see above! You say it's only a little bit easier - but
five years ago we _had_ a patch for component watching, and we didn't
have one for everything-watching. The patch was turned down, and five
years later we still have neither feature.

I would politely suggest a better rule would be to ask the patch
submitter if they were interested in doing the generic feature. If they
said no, and if no-one else was working on it actively at that exact
moment, take the patch - even if you think generalising it isn't hard at
all. If it's not hard, then someone can do it as a further development :-)

>> - 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.

I'm afraid I don't agree. The success of things like DevMo have been
their easy editability. Manual hacking of XML-based markup is not easy,
even if its compilation becomes easier.

> 	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. 

I presume you mean these edits?
https://wiki.mozilla.org/index.php?title=Bugzilla%3AWin32Install&diff=146397&oldid=123138
I think "edited into unusefulness" is an exaggeration.

Of course they were not as well-written as the rest of the document, but
they were clearly a record of someone's experiences doing the
installation and an attempt to make the document more useful. IMO,
reverting the lot without making any effort to see what was useful and
incorporating it was unfortunate.

And you have to set that against useful edits like these:
https://wiki.mozilla.org/index.php?title=Bugzilla%3AWin32Install&diff=174547&oldid=163572

> 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.

But what you have now is no-one _editing_ the documentation. You just
have people _changing_ it (and not many people doing that either). The
structure hasn't changed for years, and the limitations and complexities
of the authoring and build process mean there are no or few diagrams,
little useful formatting, few tables, and it's very hard to take the
overall view and say "Hmm, that belongs there, and that thing there, and
then we need to edit this bit, and this bit should be a separate page,
and..." because it's all too high-friction.

And when someone does an editing patch like that, it's really hard to
review, and so gets rejected ("come back with something smaller"). That
happened to me a few years ago :-(

Moving to a wiki is not going to be 100% improvement with no downside.
But I think we'd end up with much better, more accurate and more useful
documentation than we have now.

> 	Perhaps a trade-off would be keeping the installation instructions in
> Docbook, and putting everything else into the Wiki. 

I think the installation instructions would benefit just as much, if not
more, from being in a wiki.

> But then how would
> we do localization? 

According to http://www.bugzilla.org/docs/, we haven't had localized
documentation since 2.18. Regardless, we could have a parallel set of
wiki pages just as easily as we could have a parallel set of XML files.

> Would we still be able to ship documentation with
> Bugzilla? (Is that even important?)

I don't myself think it's particularly important, but I've never had to
install Bugzilla in a location where I couldn't access the Internet.
Even machines which are isolated from the net can often be installed by
ssh-ing in from another machine which does have access, or another
machine which can sit next to a laptop which does have access, on which
you can read the docs.

But I'm sure we could ship docs anyway. There's a MediaWiki2HTML Perl
module:
http://www.gerv.net/cgi-bin/mediawiki2html

>> 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? :-)

I'd rather you read the book, because then you can hear it all from
someone other than me! ;-)

>> 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.

The trick is mapping "I have a bug in product Foo and component Bar"
into "therefore the responsible module owner is Fred Bloggs".
https://spreadsheets.google.com/ccc?key=0AjgkRw6P9EKGcGNSLWhGaXI5eDBQbi1UeFYzajJaYmc&hl=en_GB
is our attempt thusfar.

>> 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.

Lots of people who can't code provide good support. I'm sure various
admins in our newsgroups who help people have fairly rusty Perl skills.
And certainly the Firefox support community can't code. And a good
friend of mine was a mediocre coder, but a kick-ass QA person (although
he eventually went to theological college and is training to be an Old
Testament lecturer).

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla