RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

["Grigori Fursin" <gfursin at gmail dot com>]

Thanks again, Manuel! 

I really appreciate your detailed thoughts and I think they will be really 
very useful to the new-comers. By the way, I agree with them and I was just 
still trying to pass the message from the participants of the GROW workshop 
but I think that now things should be much more clear. 

I will try to create this page on GCC Wiki this weekend so that if new 
students/researchers try to approach GCC community without reading that, 
they can be gently pointed out to this page that can avoid offences and 
mis-interpretation. I hope that my colleagues will help
to update this page later since I changed the job a few months ago and
my work is for now orthogonal/not directly related to GCC so I can only 
do it in my spare time but I still hope it will be useful ...

Cheers,
Grigori

-----Original Message-----
From: Manuel López-Ibáñez [mailto:lopezibanez@gmail.com] 
Sent: Friday, April 16, 2010 6:51 PM
To: Grigori Fursin
Cc: Dorit Nuzman; gcc@gcc.gnu.org; erven.rohou@inria.fr; David Edelsohn
Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

On 16 April 2010 13:21, Grigori Fursin <gfursin@gmail.com> wrote:
>
> I think, the main problem for students and researchers is that they
> see lots of stuff going on with GCC and on mailing lists but they may
> be shy/scared/not sure where to start if they want to contribute
> or even if they will be welcome to contribute. The reason is that
> some of their ideas/work may not be necessarily immediately useful to the community
> and they may be concerned that they can get lots of aggressive, negative feedback

That is why mentoring could be helpful. Technical discussions by email
sometimes appear harsh and dry to newcomers. Moreover, negative
opinions are more vocal than positive ones. So something that most
people think is a good idea or they are indifferent may only get
negative feedback from a few.

> no matter how useful they are in the future. However, such feedback can immediately
> drive away young and motivated students who can otherwise become really active
> contributors (look at the GRAPHITE and students contributing to GCC now, for example).
>
> So, what I think could be useful, is to try to agree on what can be
> some general common suggestions/recommendations to students/researchers

A short list out of the top of my head for proposing ideas in gcc mailing lists:

* If you do not have the time/resources/people to implement your own
idea, do not expect GCC developers dropping 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 no trivial at all.

* 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, discussion is not going to solve it. The only
way is to implement your idea (or a working prototype) and give
substantial experimental evidence in many scenarios/targets that you
are right.

* If you have a great idea implemented and provide a substantial
patch, 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.

* Your email/patch may not receive much feedback. 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 (I do not read 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 feasible choice is to try again sometime later with an improved
message.

* There is also the IRC channels (http://gcc.gnu.org/wiki), which are
more interactive, but the same rules apply to them. Specially being
ignored despite people talking to each other. That is because people
are working, and sometimes they have deadlines, urgent stuff to do,
they want to go home early...

* Read the gcc and the gcc-patches lists for a while to get to know
how things work and who is who.

I am sure there are many more little rules-of-thumb I can come up with.

> who may want to contribute but not sure how to approach GCC community.
> Maybe we can make a page on GCC Wiki with such recommendations or even

Anyone can edit the wiki, so be my guest.

> maybe make a separate pre-processing mailing list for novel/crazy/future/unclassified
> ideas so that only those of you who are interested in that can follow/discuss them
> and from time to time approach this mailing list with already mature ideas
> to avoid bothering others who are distracted by such discussions on this mailing list?

An example of how *not* to get things done is this "maybe we"
attitude. It is likely to get no feedback, negative feedback, or
positive feedback that sounds a bit negative (like my "be my guest"
above for the wiki page):

* 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 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 wait 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 the above 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 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. If those people are in favour, it
doesn't matter who is against it (Of course, it many people are
against it, then the responsible may change their mind, but it also
work the other way around, so pleasing people may help to change the
opinion of the responsibles.)

> By the way, Manuel, do you mind, if I will forward you email to the HiPEAC
> mailing list?

You may forward it, quote parts or edit it for your purposes, with or
without attribution. I hereby donate it to the public domain ;-)

Cheers,

Manuel.