Results of Community Research

[Max Kanat-Alexander]

On 02/15/2010 07:12 AM, Gervase Markham wrote:
> 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.

	Oh, if it's just a month-to-month issue, then that didn't really
matter, because I was looking at trends over several months (I think 5
at the fewest) instead of looking at the month-to-month relationship.

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

	Yeah, I usually do take patches like that.

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

	Yeah, and I would accept a component-watching thing that was based on a
generic-watching thing, now. In fact, that might even be the next patch
I write.

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

	That sounds like a reasonable suggestion that I can keep in mind in
similar situations.

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

	Hmmm, well, at the moment I disagree. Perhaps an errata for the
installation or a FAQ about installation would do well in the Wiki though.

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

	Yeah, that's reasonable.

	Actually, I think I'm more concerned about providing documentation for
separate versions, which we *do* do, and is still important, because
things really do change across versions. I don't currently know a simple
way to keep several different versions of the documentation in sync on a
Wiki in the way that we can do with patches and branches.

> 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

	Yeah, that seems reasonable. I don't think it's that important either.

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

	Yeah, maybe a Bugzilla Extension that added a "manager" or something to
a Component would help keep track of it a bit better.

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

	No, that's true for sure. I've just never met somebody who *started* as
a coder, and was bad, and then went on to be a good support technician.

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