65928 - Make it easier to become a Mozilla Contributor (for Bugzilla QA volunteers and others)

Status: RESOLVED WONTFIX

(mozilla.org :: Governance, task)

Description

[Andreas Franke (gone)]

This is intended to be used as an idea collection and tracking bug for efforts
that will make it easier to become a mozilla contributor and help fix bugs.

If you think that there is no need for such a bug, feel free to mark invalid.

Comment 1

[Andreas Franke (gone)]

Adding dependency on bug 57237: "Outside developers need more documentation"

Comment 2

[Andreas Franke (gone)]

Bug 35552 "HOWTOs" http://www.mozilla.org/HOWTO/ seems to be the only other
interesting documentation meta-bug I found, but it looks like it's old and
stale.

Comment 3

[Fabian Guisset]

Andreas : Thanks for the great idea.
My thoughts : This bug should kept only to summarize ideas that have been
discussed elsewhere, namely in newsgroups. I like having a bug references
because it's easier to find than a newsgroup message, but having a discussion in
a bug, mainly if a lot of parties are involved, quickly becomes a mess.
Also, in case you were not aware of it, the mozilla.org website is undergoing a
complete face lift. This is currently discussed in the npm.documentation
newsgroup, if you are interested in it.
Last thing, I think we need to spam the npm.qa.general newsgroup a lot more to
get feedback from other QA's concerning some bugs, so those not on IRC all the
time also get a chance at helping out.
So in brief, what I propose is this :
Let's keep this bug open (or actually open a new clean one which doesn't have
these introduction comments), but write in it only the decisions that have been
taken. Also since I am going to be part of the team that will help with the QA
documentation for the new website, anything that is written down here should be
translated to a real html doc.
Here are my thoughts, feel free to comment.
Adding a few QA's to CC for their input. Adding doron as QA contact.

Comment 4

[Doron Rosenberg (IBM)]

my first patch went in yesterday...and the tree remained green, believe it or not.

i think the mozilla.org reorganisation should include a "fixing bugs for idiots"
type section, with some simple info and links (xulplanet for example).

Comment 5

[Andreas Franke (gone)]

I think having a bug for summarizing discussion results is a good idea. But I'd
like to keep this one open for Random Rambling, and as the root bug of a
dependency tree. Please file the summary bug and post the bug number here. We
should then add to this bug an ASCII-art comment like the one from Pierre
Saslawsky 2000-09-29 17:11 in bug 4830 saying that the summaries can be found in
the other bug so that when this bug is very long and someone starts reading it,
s/he will be know at straight from the start that much time can be saved by
reading the other bug only. People are free to CC them only on the "summaries"
bug if they fear to be spammed here :) The "summaries" bug could point to the
corresponding HTML web page in its URL field.

I won't have time to read any mozilla newsgroups for at least the next year, so
if you see some important post there you want me to read, please CC me or
(preferably, if on topic) post a link to it in this bug.

I know about the website reorg and the newsgroup reorg, and I think this is a
great opportunity to design things from the start to help new contributors get
up to speed. And yes, npm.qa.general should be used more :)

Comment 6

[Andreas Franke (gone)]

Actually, I'd like to generalize the summary a bit: I want to have this as a
generic umbrella bug since I want everybody to become a Mozilla contributor :)

I'm adding a dependency on the newsgroup FAQ meta-bug 65447 because not having
FAQs causes knowledgeable people to spend a lot of time answering questions in
the newsgroups that could be spent improving mozilla.org's usefulness, and/or
causes potential contributors to give up early if their questions aren't
answered.

Comment 7

[Andreas Franke (gone)]

Doron: I like "Bugfixing for dummies" etc. :) There is no website reorg
meta-bug, is there? I think there should be one to summarize the design goals
wrt. making it easier for people who are new to mozilla to become contributors
(i.e. help fix bugs). If you file one, please make this bug dependent on it.

I'm adding the "make bug-finding easier" meta-bug 65929 to the dependency list.
I can see two reasons why easier bug-finding would serve this bug:
(1) Even Mozilla contributors will sometimes need to search for bugs. The easier
they can find them, the more time they can spend on fixing them.
(2) Searching for bugs is a frequently performed task when doing QA work. One
reason for QA volunteers not becoming Mozilla contributors may be that they feel
Bugzilla needs them. :) If bug finding becomes much, much easier than it is now,
it will take less time, and it won't have the aura of a science any more. Thus
it may help people to migrate from Bugzilla QA work to coding more easily.

If this is too controversial, feel free to remove that dependency again.
Anyway, this is all my thoughts only. This bug is yours now. 
Good luck, and let mozilla shine :)

Comment 8

[Jesse Ruderman]

Adding 62773 because I'm to lazy to pirate MSVC.

Comment 9

[Doron Rosenberg (IBM)]

get linux, cheaper than msvc ;-)

well, the easiest thing for "newbies" to hack on is xul/js. we could list all
those bugs on a page somewhere and such. stepehend told me yesterday that
mailnews has a lot of context menu work needed, that's another easy thing.

i have no idea who is running the website reorg, was it gerv? hopefully, i will
get cvs rights soon enough, maybe i can upload such pages into the qa dir.

Comment 10

[Andreas Franke (gone)]

XUL/JS are good things. But please don't forget about all the C++ hackers out
there who aren't very much interested in learning XUL and other mozilla-specific
technologies, but may be able to help fixing some C++ code bugs. Ideally, there
should be tutorials like "How to fix bugs in the table border code" ;-) I think
there are even some [C++ hackers] with Bugzilla accounts right now.

Comment 11

[Bernd]

How to fix bugs in the table border code.

the tutorial is very short:

Wait for Chris Karnaze until he makes the BIG checkin, enabling again the border 
collapse code.

I am working on a help file for debugging options inside the table code.

Comment 12

[Andreas Franke (gone)]

Can someone please file a placeholder bug for the website reorg with pointers to
important resources (web pages for STT & LTT, maybe some key newsgroup postings)
related to the effort? Thanks. Please post the bug number here.

Comment 13

[Andreas Franke (gone)]

From http://freshmeat.net/news/2001/01/27/980657999.html (mentioned on
mozillazine at http://www.mozillazine.org/talkback.html?article=1811 ):

> The problem is [...] that [Mozilla] is difficult to understand. Heck, simply
> compiling it can be tricky. Getting up to speed on Mozilla appears to be
> difficult, so contributing is difficult.
 
> Open Source objects seem to do best when a replacement can be written by a
> smart teenager during summer vacation or as an after hours project
> of an experienced sysadmin. [...] This is probably the core of the Open Source
> world, [...]. 

> Mozilla is much larger than most Open Source projects. Becoming a contributer
> is hard. Writing a replacement is harder. 

> So, we have a problem. Mozilla is too large to attract casual programmers in
> the numbers it needs, [...].

> One [approach to the problem] is to have more people working on Mozilla.

Comment 14

[Jesse Ruderman]

Adding bug 20962, anonymous cvs access for gila (www.mozilla.org content).

Comment 15

[Vaclav Dvorak]

Is there a public server somewhere that offers shell accounts where I could
checkout Mozilla CVS, do some hacking, and build Mozilla for at least Unix (and
ideally Windows, but cross-compiling is not possible, I guess), and perhaps even
run it, with remote X display? That would be the killer "easification", at least
for me.

In many parts of the world, bandwidth is a very scarce resource, and downloading
40MB of source is nearly out of question. Add to it the CPU power required to
build the tree in a reasonable time, and the disk space requirements...

Comment 16

[Gervase Markham [:gerv]]

> Is there a public server somewhere that offers shell accounts where I could
> checkout Mozilla CVS, do some hacking, and build Mozilla for at least Unix... 
> and perhaps even run it, with remote X display? 

Surprisingly enough, free shell accounts which give you 2GB of disk space,
development tools and the ability to use the entire CPU of the box for 2 hours
are somewhat hard to come by. :-(

Gerv

Comment 17

[glenn n. davis]

I have noticed that bug searches have problems with natural language: the main
one being that there are many words for some problems all valid but hard for a
search engine to handle.

A thesaurus might be helpful to find useful meanings to select the right words
to put into bugsearch. Also some way to cut out un-intended meanings from searches.:
perhaps a (A or B or D or G)AND (L or M or Q) format where capital letters
represent click choices for meanings from a thesaurus and there were two entries
which should be both present. Prefered word choices could be bolded so that more
users could use consistant language to describe bugs without being forced to do so.

A thesaurus might ask "Do you mean":  A B C D E F G for the first word.
                      "Do you mean":  L M N O P Q R S  with check boxes for each
option for each word.

I know this sounds confusing Perhaps someone could say it better.  I wont be
offended.

The point being that having a more user friendly  search for my bugs would
enable me with good faith to recognise my bugs as duplicates of someone elses 
work who has perhaps already written the "wheel" that i am trying to describe.

Comment 18

[Reed Loden [:reed]]

--> Governance

Comment 19

[Reed Loden [:reed]]

zak: Please only change the assignee and not the QAContact when you are taking a bug. Many of us watch the QAContact for changes with Governance bugs, and by changing it, it causes bugmail to be lost and never seen. Thanks!

Comment 20

[Zak Greant]

Is this really a governance bug?

Most of the discussion centers around what resources novices might need, rather than about something plausibly governance-related (liks should new people be allowed to commit, who decides who gets access, etc.)

Comment 21

[Zak Greant]

We do need to get better at helping new users get started, but this isn't a governance issue per se (and we have this more clearly documented in other places)