Making It Easier To Start Working On Bugzilla

[Mick Weiss]

For starters, I think that it would be a great idea to try to make it 
easier for people to help out. :-D

I agree with a lot of the points, but I don't think that people should 
be working on blockers as their first task. I hear this a lot in 
projects, "Oh your new? Try to take on a blocker". Small enhancements 
are probably the best place to start for new people as blockers are 
often difficult and are better solved by people who know the code a lot 
better.

Here are my 2 cents:
- An introductory document with a general layout of class structure and 
how things work would be helpful for new people, but AFAIK doesn't exist.

- I agree with having a contributors document, going over what happens 
with a patch (example: who should get the "review flag", what is it and 
why is it there and what to do if a reviewer doesn't have time to review 
your patch... that sort of stuff).

- Maybe a document on an example patch would be interesting. "The 
step-by-step guide to creating a patch for Bugzilla", with an example 
patch (something not too incredibly hard). It would outline the problem 
and places the author looked to for info on solving a particular problem 
(like the Bugzilla POD, developer docs, other places in the source...). 
It could even say "checkout this version from cvs and follow along". I 
for one think that it would be a good idea, but that is just me ;-)

- Right now, when patches are submitted - sometimes it takes a while for 
a patch to be merged into a release (one example off the top of my head 
is https://bugzilla.mozilla.org/show_bug.cgi?id=250916 which has been 
sitting there since 2004). To quote Dave, "Note that this has already 
missed the boat for both 2.18 and 2.20". I am aware of the issues behind 
this patch, but what I'm saying is - if you write a patch in 2004, and 
it is 2 weeks from 2006 and no real advancements have been made... would 
you want to contribute again? I know not everyone has LDAP/TLS setup to 
test this... but it is just meant as an example to backup a point.

- Another issue is that patches need to be maintained from version to 
version, and some people submit a patch and then noone ever hears from 
them again. I don't really have a solution for this, but I have seen 
this with other projects. (I'm not sure if this is really an issue for 
Bugzilla).

- Mick



Max Kanat-Alexander wrote:

>	So, I'm always really happy to have new people working on Bugzilla, but
>I think that sometimes the barrier-to-entry is a bit too high. Let's
>work out some ways that we could lower it.
>
>	Here's some thoughts I had:
>
>	1) We don't have any brief, clear documentation on the way that the
>Bugzilla Project uses Bugzilla, or what our actual development process
>is. I didn't realize this until I had to actually explain it in IRC the
>other day, and didn't have any document to refer to. :-)
>
>	2) We don't have any way to point new contributors to the bugs that
>they should work on. It's true that we have the blockers, and that's a
>good place to start, but there are a lot of other easy bugs that would
>be a valid place to start off contributing.
>
>	3) We don't really have any sort of defined "channel" (in the
>theoretical sense, not in the IRC sense) for new contributors to travel
>in. That is, we don't exactly have a written process for "This is how we
>handle people who want to contribute to Bugzilla." We have the
>Contributor's Guide, but that's more a list of "dos and don'ts."
>
>	Any other ideas? Any other barriers that new developers out there have
>run into? I'd really like to have a *lot* of developers, which would in
>turn lead to a lot of reviewers.
>
>	-Max
>  
>