From incoming answers I seem to understand that everybody knows something but
there's no clear consensus of what should be done when. I could see a tendency
that Eclipse doesn't care, *how* GitHub is used, since everybody can just search
the net for how others are using it.
I believe that is true, but I don't see it as an issue.
Developers have tailored workflows that fit their preferences, their experience, their habits... Those workflows are built according to documentation, experience or other sources of knowledge that are rather personal, so it's not surprising that different people have different workflows, it's a form of diversity in action. And all those workflows may even be the best ones in their context.
IMO, projects can and should embrace these diverse workflows as long as all those workflows do lead to "good enough" quality. Projects should specify the actual constraints on the resulting contribution, not the way contributions are made.
But indeed, it can be useful to have some of those workflows documented somewhere for "educative" purposes.
If, however, JDT still prefers a coordinated, somewhat uniform approach, I'd
suggest: let's first agree on *where* the results of this discussion should be
captured (I regard a mailing list as the least suitable option for this).
As mentioned, I don't think the project should aim at preferring 1 uniform approach when there are multiple working approaches. That would be adding constraints on some contributors without clear benefit for them nor for the project. If those constraints happen to make some developers less productive than usual, they'll be less likely to contribute.
So project may promote 1 or several workflows, but not enforce or require a particular one if some others are working as well for some people.
Should we maintain jdt.core's CONTRIBUTING.md accordingly? Should we coordinate
and push this into the next level (JDT)?
The CONTRIBUTING.md file is indeed where such guidance would fit best, adding a section with tips for typical review operations.
