Hi, I'm not sure if I'm missing something, but the conversation looks for me as there is either the one or the other way. Either edit in a git branch directly (incl. master) or fork everything.
I see Justin/Chis' point in some way - keep it simple. And I agree. Working on the project should be as less laborious as possible. But I also agree Lars' Point of view. It's important to keep on regularity. Without it you are losing the overview because of dozens of single "standards". But then I am thinking about what we are doing here: We are talking about slides for a presentation - not the control unit for a nuclear power plant. A strict order is important (especially for a german like me ;) ) but I think changes on slides should be allowed to be done as easy as possible. As a non-commiter who is willing to help, I have to accept that there are people who edit the code right in the master branch while I'm not allowed to do so. But I know that they have done this more often than me before. The (hopefully) know exactly what they are doing. Their contribution is not better than mine. Besides this, perhaps you could even split the check in process for commiters. Allow changes on the content of the slides directly. Changes on the other stuff (content of the website, the "engine" for building the slides, etc.) should be branched. So my conclusion/opinion after reading this conversation is: Allow both. Commiters should allowed to change slides in the master directly and need a branch for changes on the remains. People like me have to do a PullRequest. Oli -----Ursprüngliche Nachricht----- Von: Justin Mclean <[email protected]> Gesendet: Freitag, 17. Mai 2019 01:54 An: [email protected] Betreff: Re: Git branches Hi, > Again: You've done it exactly like this with all your pull requests so > it seems to work for you? Because I was asked to do it this way. The process has been sub-optimal IMO. > With "this" I mean that people prepare content (e.g. patches) outside > of ASF infrastructure and then submit said content to various projects > (which are then often reviewed and iterated on, etc.). This has been > the standard way to operate for as long as I can think. For external contributors yes. > None of my concerns are related to Github, in fact, I didn't even use > that word in my initial mail. A pull request is a gifthub feature its not a feature of git, git uses patch files. (Although it recently added a similar feature via the request-pull command which generate a summary of changes.) Some context may help, there’s currently 2,634 people in the ASF GitHub organisation [1], which is about a 1/3 of the total ASF committers (currently 6901). > Still: There will always be more people not having access than people > having access even if we give someone committer status after the very > first contribution. I’ve not seen this on projects I’ve been on, usually the committers/PMC members outnumber the external contributors. It may be different on very large popular projects like Spark, but that’s probably not a good example for a number of other reasons. > Do I understand you and Chris right that you'd like to have branches > for every little issue that anyone (whether the person is a committer > or not) wants to contribute? For small stuff why even have a branch? Work right off master. For larger stuff it best to work in one sure. External contributors can choose how they want to work forcing people down one path may mean they don’t contribute. If someone puts some power point slides as an attachment in a JIRA and asks would we like them, (licensing consideration aside) I’m not going to turn around sorry I cannot accept that, you get to get a GitHub account and fork the repo, make a branch and provide a pull request. Thanks, Justin 1. https://github.com/orgs/apache/people
smime.p7s
Description: S/MIME cryptographic signature
