Hello Mathieu, > How do you usually proceed on an unknown codebase? Checkout the code, see if > it works, how it works and what is broken. Try to fix what's broken and > improve the stuff to fix your needs.
The order is correct. But I'd say that there is a long way to go from "checkout the code" to "improve the stuff". If we don't find ways to help newcomers along that way, I don't expect many to reach the point where they can contribute patches. Surely not three at the same time for a single podling. For starters, we need a place for volunteers to meet. A wiki page where volunteers can enroll has been suggested, +1 to that. There also needs to be a mailing list, and I don't think that [EMAIL PROTECTED] is suitable for that. If people are interested in reviving a failed podling and waiting for two other volunteers to arrive, you can't ask them to monitor a list with hundreds of unrelated mails each month. They'll just give up and unsubscribe after two weeks. Are the mailing lists of retired podlings kept open for communication and commits? If not, I suggest to create a dedicated mailing list [EMAIL PROTECTED] It can be the target for the JIRA and commit mails. The response to a volunteer for a retired podling would then become: 1. enroll yourself on the Wiki page 2. subscribe to [EMAIL PROTECTED] 3. play with the code while you're waiting for other volunteers 4. post questions to revival@ where a few oldtimers and maybe other volunteers should hang out If a podling is retired for lack of community interest, the people familiar with the code that just don't have the time to work on it can subscribe to revival@ to later help newcomers get started. WDYT? cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
