Since I have been around no more than one year, perhaps my perspective could have some interest for the discussion.
I am not sure if a new list will help. Some have argued that long time developers may be discouraged to participate in such list and that new developers would be discouraged from participating in the main list. I think both are pretty good arguments. Nevertheless, I think the problems mentioned by Diego do exist. When you are starting most of the questions seem silly. Many of them actually are. When you gather the courage to send it, sometimes it gets ignored or worse they point you to an amount of documentation which is mostly irrelevant for the answer, or worst, it is incomplete or outdated. Of course, this is not always the case and there are very good reasons for it: people are busy, the question was unclear/confusing/plain-stupid. Just an example. There are people that post patches in bugzilla and they seem interested in getting them integrated but normally they break coding style or don't have changelog or didn't even run the testsuite. Of course, the easiest answer is to point to the "how to contribute" webpage. I have done it too. But I must admit that it is a poor answer. When I started, I couldn't bring myself to read all that was required to post a proper patch. Fortunately for me, Ian had a lot of patience to mentor me and some folks were so kind to teach me how to submit a proper patch. However, I don't think that is the typical situation. Another recent example: http://gcc.gnu.org/ml/gcc/2007-07/msg00456.html (Not a single answer). Summing up, I am not sure whether a separate list would help but in my opinion there are a few things that will: * Mentors: I think it has worked great for the Google Summer of Code. Why not make it something more common? I will propose that if someone wants to fix a bug or work on something, the maintainers on this area should try to find a willing and suitable mentor. However, don't wait until someone steps up. The maintainer knows who is knowledgeable in the area, so ask those people until someone agrees. Perhaps what we need is gcc-mentors@ * Documentation to learn. GCC has a lot of documentation. But it is mostly for reference, that is, if you forget some detail or it is under discussion, there is plenty of documentation. However, there is little aimed to teach (with examples) the steps of how to contribute. It is like telling people to learn programming by reading the ISO C standard. The wiki is slowly changing this, but it still needs a lot of work. Regarding this, there is a curious effect that I experienced myself. When I started one year ago I noticed the lack of simple howtos describing the basic things like "how to submit a patch", "how to prepare a testcase", etc. However, as soon as I learnt how to do it, the task of describing them for newbies felt extremely tedious. * Be careful with the answers and be explicit in what the next step should be. For example, for someone that does not follow gcc-patches it can be discouraging to get her patch rejected just because it lacks a changelog or some coding style issues. It is good to convey that this is not nit-picking, that the patch is welcome and that we want that person to please send the patch again. Rober Dewar says that "in my impression beginner *developers* get good/polite answers and indeed I think people usually go out of their way to help". I would say that this is true for people that have been able to commit their first patch. That kind of beginners know what it takes to submit and commit a patch, understand what a review is, understand what is worth discussing and how the decision-making procedure works. However, I don't think the situation is as good for people that are struggling to figure out how to commit that first patch. OK, I think this is far enough. Cheers, Manuel.
