Making It Easier To Start Working On Bugzilla

[Emmanuel Seyman]

[ Apologies. My webmail sent the previous
  mail without asking for permission first ]

mkanat started this discussion saying (amongst other things) :
>
> 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.

I really don't think giving newcomers blockers to fix is a good idea.
Once developpement is in freeze (as it is now), blockers really need
to be fixed ASAP. Giving these to newcomers probably won't help.

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

Every once in a while, I find myself wishing for two new fields in a
Bugzilla bug report :

Difficulty : How hard is it to resolve this bug (no idea who would set
this, though).
Field of resolution : Does the person who will try to resolve this need to
know TT ? HTML ? Docbook XML ? Perl ? Any combination of the former ?

This would enable us to point a newcomer who only knows HTML to the
appropriate bugs and let them go at it without fearing they're out of
their depths.

Mick Weiss added :
>
> 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.

Very true.

Jochen Wiedmann then said :
>
> Do you think, it is encouraging to provide a patch the next time, if my
> suggestion is rejected simply because the reviewer does not like my
> wording? Do you think it is likely that I take the work the next time?

While it's frustating to have your fourth patch for a bug get a negative
review because of one mistake, it's a much more effective way of making
sure that the contributor won't make that mistake again.

> I wholeheartly support your concerns for quality. But isn't that
> exactly the reviewers job? If he does pull a patch in, applying
> necessary changes, isn't that enough for quality? If it is not, then
> he possibly should stop review.

The problem is that we have far fewer reviewers than contributors.
It makes sense to shift the burden of developpement on the former more
than the latter.

Emmanuel