> My thoughts are that we encourage potential contributors to sign up > for a GitHub account and use pull requests whenever possible for > submitting changes.
Sure, for new contributors, this is how things usually work with Github, and it's a very good solution. In fact my answer was to Henry, thinking about long-time contributors like him, but for new developpers, it's different. > Even when I'm confident in my code, I always > prefer to get feedback on it before merging it in, just in case I've > overlooked something. The backwards compatibility for > `\includescore` for instance is a good example where the discussion > revealed a point of confusion in my original code and led to changes > to make it clearer. Even if no one comments on the request, the day > or two of breathing space between submitting the pull request and > merging it in prevents me from making changes rashly. You're right. A possibility is also to make a rule saying that one cannot merge his own pull requests, so that someone "takes the responsibility" (although we shouldn't be too serious about it) to proofread it (not always in every detail) and merge it (or not). What do you think? Also, note that having a separate repository is not mandatory for pull requests, they can be done inside the main repository. But we can also say that working directly on the main repository should be avoided. I'm the main culprit of this not so good practice, but I'm ready to change for a cleaner solution! > Also, I may be mistaken, but in order to push to the main repository > a person has to added to the project as a contributor after setting > up their GitHub account. Yes > This would hold up their ability to > contribute until Élie (or someone else with the necessary privileges) > was able add them. Thus I would suggest that first time contributors > fork the repository, allowing them to upload commits and submit pull > requests right away. Sure, sorry for my blur previous answer, it should have been considering this case. > Finally, while I think creating an issue is a good idea when one > isn't sure whether or how to implement something or simply doesn't > have the time to do so right that minute, if one has a solution ready > to go, then skipping straight to the pull request is okay. GitHub is > very good about making discussions about pull requests seamless. Yes, after all, why not... I admit I'm using issues mainly to remind me of what I have to, otherwise I'd keep forgetting everything (because the list is way longer than I'd like). Thank you, -- Elie _______________________________________________ Gregorio-users mailing list [email protected] https://mail.gna.org/listinfo/gregorio-users
