The main channels to interact with the GCC community are the mailing lists (gcc and gcc-patches at least), IRC (if you like that) and Bugzilla.

Some informal suggestions on how to interact with the GCC community

  1. Ask for help. Mentoring could be helpful for you. You could ask in the gcc@gcc.gnu.org mailing list for a mentor by stating your interests. You may also consider starting by applying to Google Summer of Code.

  2. Be excellent to others. Follow normal etiquette rules, in particular, the "No Obligation" rule is applicable even outside GCC Bugzilla. Karl Fogel gives general good advice on how to communicate effectively within a free-software community.

  3. Look at the bright side. Technical discussions sometimes appear harsh, terse and dry. It is also difficult to judge 'tone' in non-face-to-face channels such as email and IRC. Thus, one should always assume the most friendly tone when reading others, esspecially if they criticize our ideas. Moreover, negative opinions are more vocal than positive ones. Thus, something that most people think is a good idea or they are indifferent to may only get negative feedback from a few. Take this into account when judging how other people evaluate your ideas.

  4. Scratch your own itch. If you do not have the time/resources/people to implement your own idea, do not expect GCC developers to drop what they are doing to help you. Volunteers have very, very limited time and paid developers are paid to do something else. In fact, asking GCC developers to do anything for you, no matter how trivial it seems to you, will likely result in negative feedback. Probably it is not trivial at all.

  5. Prove that you are right. If your idea may potentially slow down the compiler, increase memory consumption, increase complexity, remove features, or change defaults, it will receive negative feedback. Guaranteed. If you are sure that this is not the case or that the benefits outweigh the drawbacks, but GCC developers disagree, passionate arguing is not going to solve it. The only way to prove that you are right is to implement your idea (or a working prototype) and give substantial experimental evidence (numbers!) in many scenarios/targets.

  6. Develop within the community. If you have a great idea implemented and provide a large patch out of the blue, expect negative feedback. There are many ongoing projects in GCC. A patch that comes out of the blue and breaks those projects will not be welcome by the people working on those projects. Moreover, there may be already consensus on how to solve something and how not to solve it. By not asking for feedback about your approach earlier, you are likely to miss this information and your approach might be considered counter-productive. Conclusion: ask for feedback early, show early prototypes, take into account suggestions.

  7. Keep trying. Your messages might get ignored. This may happen if you provide your idea in an old thread (people stop reading long threads after a while), your subject line was not interesting/descriptive enough (almost nobody reads all emails from the list), the main audience of your email just missed/overlooked it by chance (bad luck, busy period, vacations), your email was too long (people stopped reading before reaching the interesting part), ... The only solution is to try again sometime later with an improved message. The IRC channels are more interactive, but the same rules apply to them, esspecially being ignored despite people talking to each other. This is because people are working, and sometimes they have deadlines, urgent stuff to do, they want to go home early...

  8. Keep pinging. There are many reasons why reviewers may overlook your patch: lack of time, accidentally deleting, not clear who should review it, patch is too complex, not the appropriate development stage. Even patches from experience developers require several pings. "Pinging" a patch after two or more weeks without an answer is common practice. More examples of pinging. Tips:

    • Add PING to the subject. You can also add a counter of how many pings you have done already.

    • Either add the entire original email (patch, changelogs and explanations) or send a link to the original mail in the archive. Make things as easy as possible for the reviewers

    • Add maintainer areas to the subject such as [PATCH C/C++/testsuite/driver]] (a patch that adds a testcase should not be marked testsuite, that is only for changes in the testsuite infrastructure). If some parts are reviewed but others not, trim the subject and CC list appropriately.

  9. Learn by example. Read the gcc and the gcc-patches lists for a while to get to know how things work and who is who.

  10. You only need to convince the decision-makers. Almost the only feed-back that matters is the one given by those that can approve or reject your change. In the case of a patch, that's the maintainers of the area touched by the patch (see the MAINTAINERS file). If those people are in favour, it doesn't matter who is against it. Of course, if many people are against it, then the decision-makers may change their mind. It also works the other way around, so pleasing people may help to change the opinion of the decision-makers. But your goal is to get the approval of the people with the power to approve.

  11. Be precise and pro-active. An example of how *not* to get things done is the maybe we attitude. It is likely to get no feedback, negative feedback, or positive feedback that sounds a bit negative (like be my guest):

    • It does not specify who is "we". It could be understood as asking the reader to do something that takes time and effort. Everybody is busy already, so that's a bad strategy. It can also be understood as only you or people that you know already that are going to do it. So the reader understands that he/she does not need to do anything and just waits for you. Hence, if you were expecting feedback/action, you will be disappointed.
    • "maybe" is vague. Vague ideas are ignored or criticized because either there are not enough details to have an opinion or it is easy to misunderstand them. For example, a better way to move an idea forward would be:
      1. Send a new email with a descriptive subject "A new gcc mailing list for experimenting with gcc"
      2. Say: "I would like to create a new mailing list gcc-experimental for this and that. I know so many people that are already interested to join. I would like to create it in the gcc servers. Who is responsible for creating a new mailing list?" (If overwhelming negative feedback from the responsible then a further email) "OK, no problem. I created the mailing list in google groups, this is a patch to add a link to it in the GCC webpages." (let's assume the unlikely case that you still get very negative feedback from the responsible of the webpages) "Oh, I see. I understand your concerns, I will add a link to it from the wiki page. Anyone interested is welcome to join. Thanks! :-D"
      3. Expect some negative feedback, some bike-shedding I prefer the name gcc-crazy-ideas.... And bear in mind that you only need to make the changes that are asked by the decision makers for your problem, in this case, the people with the power to create the mailing list, approve patches to the webpages. (See point above)

None: Community (last edited 2016-08-01 11:43:28 by JonathanWakely)