| Re: [jdt-dev] Telling GitHub to rebuild, rebase, ... |
|
Well, in a perfect world, where everyone is contributing in a vacuum, I guess we all can do whatever workflow
that suits us. But in a project where people work with one another, some sort of guideline or recommendation is always good for a smooth functioning of the project. For e.g, Stephan’s concern of force-pushing a branch by a contributor. In this case, it’s better if the contributors follow a certain way so that it helps the reviewer do his job comfortably. In other words, what’s good enough for someone may not cut
it for someone else. Having said that, we don’t want to restrict someone to the point of affecting their productivity. We don’t want to be unreasonable here. But at the same time, I am pretty sure there are newbies and
some seasoned contributors that would like some sort of recommendation. I don’t see this affecting the level of contribution at all. FWIW, I don’t see any noticeable difference in new contributions after moving to GitHub. And I like the idea of having one for all the JDT projects. That should be the way forward. Regards, Jay From: jdt-dev <jdt-dev-bounces@xxxxxxxxxxx>
On Behalf Of Mickael Istria Hello, On Sat, Sep 10, 2022 at 1: 22 PM Stephan Herrmann <stephan. herrmann@ berlin. de> wrote: 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 ZjQcmQRYFpfptBannerStart
ZjQcmQRYFpfptBannerEnd Hello, On Sat, Sep 10, 2022 at 1:22 PM Stephan Herrmann <stephan.herrmann@xxxxxxxxx> wrote:
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.
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.
The CONTRIBUTING.md file is indeed where such guidance would fit best, adding a section with tips for typical review operations. You may like to remove the CONTRIBUTING.md from eclipse.jdt.core and eclipse.jdt.ui GitHub repo and instead enrich the common one that is located at
https://github.com/eclipse-jdt/.github/blob/main/CONTRIBUTING.md |