-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More Details on the recommened contribution workflow #120
Comments
It looks fine to me. I should note though that I don't personally find this setup quite ideal. The automatic Oomph setups clone the original repository and then it's easier to add your personal fork as an additional remote rather than the other way around. To my thinking this has the major advantage that when I switch back to the master branch locally and I do a pull, it pulls from the real original repository not from the master branch of my fork. Therefore I do not need to sync the master branch of my fork manually with the master branch of the original repository because nothing ever works with the master branch of my fork, e.g., Not having to worry about syncing my forks via the web page, especially when I have two dozen repos in the workspace, is a big win... |
Ah ok. Didn't know that. But the existing description already started with cloning the fork and not with cloning the "upstream" repo. So I continued on that road. |
Thank you for updating the workflow description, @BeckerWdf! The changes also look fine to me. I personally also prefer the workflow mentioned my @merks. But finally that's a matter of personal preference. Maybe we can split the description into two parts:
The benefit I see from splitting up the information is that (1) is revelant for every (new) contributor, while (2) is only relevant for those new to Git/GitHub workflows. So for those who are already familiar with Git workflows, it would become easier to filter the relevant information for them. Another point for which there does not seem to be a common agreement across all eclipse-platform repositories is;
At least in the |
That's a good idea. |
…tform#120 The CONTRIBUTING.md describes the contribution workflow combining the information for how to set up and manage a fork and for how to create and process a pull request. This change separates the two parts of the contribution process into separate sections. In addition, is extends the explanation of how to manage the local clone for a fork by an alternative workflow of having the main Eclipse repository as the origin remote. To conform to recent repository merges, the change also clean ups the list of repositories in the Eclipse platform organization. Contributes to eclipse-platform#120
The CONTRIBUTING.md describes the contribution workflow combining the information for how to set up and manage a fork and for how to create and process a pull request. This change separates the two parts of the contribution process into separate sections. In addition, is extends the explanation of how to manage the local clone for a fork by an alternative workflow of having the main Eclipse repository as the origin remote. To conform to recent repository merges, the change also clean ups the list of repositories in the Eclipse platform organization. Contributes to #120
I think regarding "recommened contribution workflow" this is fine. |
Sorry, I'm late in this discussion, but I find much of the new documentation is more or less duplicating documentation that is already provided by GitHub. IMO, it's better to reference external documentation, as it's more likely to be up-to-date and also it demonstrates that the project uses relatively "standard" workflow, which many users already know. |
I agree, maybe the change moved the documentation into a wrong / too verbose direction. The recent change was motivated by the fact that the previous documentation proposed one specific workflow although there are multiple, equally valid ones within the standard fork-and-pull workflow. But it is true that there is now too much information that is generic / independent from this organization, and thus probably better maintained at some more "central" place. For example, GitHub provides quite some information about the fork-and-pull model, different aspects of working with forks in general, and creating pull requests.
|
The contributing information on how to create a PR is a rather verbose and slightly unstructred list of entires, which must not necessarily be relevant in the current order. This change adds a reference to the GitHub documentation on the standard "pull request from a fork" workflow that we follow. It also structures the workflow into five steps (preparing, creating, updating, validating and merging a PR), reducing the general information given by the standard workflow and putting more focus on Eclipse-platform-specific information. Contributes to eclipse-platform#120
…m#120 The contributing information on how to create a PR is a rather verbose and slightly unstructred list of entires, which must not necessarily be relevant in the current order. This change adds a reference to the GitHub documentation on the standard "pull request from a fork" workflow that we follow. It also structures the workflow into five steps (preparing, creating, updating, validating and merging a PR), reducing the general information given by the standard workflow and putting more focus on Eclipse-platform-specific information. Contributes to eclipse-platform#120
…m#120 The contributing information on how to create a PR is a rather verbose and slightly unstructred list of entires, which may not necessarily be relevant in the current order. This change adds a reference to the GitHub documentation on the standard "pull request from a fork" workflow that we follow. It also structures the workflow into five steps (preparing, creating, updating, validating and merging a PR), reducing the general information given by the standard workflow and putting more focus on Eclipse-platform-specific information. Contributes to eclipse-platform#120
I finally found the time to come back to this discussion on the level of detail / verbosity of the contribution workflow documentation in the I am not sure about the information given in the section on creating and managing a fork. I do not see any information in that section that is specific to this project. Everything can, in theory, be derived from the standard fork-and-pull model that we also reference to. Still I experienced in the last months that it was helpful for several new contributors to have such a condensed description of the process specific for the Eclipse platform to get started quickly, as other description are usually more general and verbose. So I do not think that we should remove that information completely. It may make sense to move this information into the wiki and link from the CONTRIBUTING.md to the wiki instead of having such a verbose CONTRIBUTING.md. But then we should have some agreement on the expected level of detail in the CONTRIBUTING.md and on what information we expect to be placed, e.g., the wiki. |
The contributing information on how to create a PR is a rather verbose and slightly unstructred list of entires, which may not necessarily be relevant in the current order. This change adds a reference to the GitHub documentation on the standard "pull request from a fork" workflow that we follow. It also structures the workflow into five steps (preparing, creating, updating, validating and merging a PR), reducing the general information given by the standard workflow and putting more focus on Eclipse-platform-specific information. Contributes to #120
@mickaelistria do you have any remaining concerns with respect to the current state and level of detail of the contributing workflow information? Otherwise I would propose to close this issue, as I do not see any directly addressable demands or proposals remaining. |
I just did unintentionally pushed my proposed change to the CONTRIBUTING.md directly to the main branch instead via a PR.
Sorry for that.
See : ad7a5ef
That's what I did:
Is this change ok?
The text was updated successfully, but these errors were encountered: