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.
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.
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.
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).
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 :)
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.
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 :)
Adding 62773 because I'm to lazy to pirate MSVC.
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.
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.
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.
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.
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.
16 years ago
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...
> 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
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.
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!
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.)
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)