-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
mbringingstool:
Without a contributing.md the process for contributing is a mystery.
I think we can adapt one from https://www.contributor-covenant.org/.
I think because this will be an educational setting it would be good to go through the whole process. Setting up a local copy of the code, setting local upstream/origin, submitting issues pull requests, commit format, and commit squashing.
wkjid10t:
For simplicity and student participation. I would recommend a simple 1 remote branch (maybe 2) system. master (stable) and dev. Have everyone work on dev. Then when it's stable, whoever is maintainer can then merge into master as needed.
Students make a local feature branch every time they work on something. The only thing students need to know is how to handle merge conflicts with this system.
Example: Implement hello world
pull fresh dev branch
create and checkout local hello_world branch (from fresh dev)
code and commit on hello_world local branch until the feature works
pull remote dev again to refresh
merge local hello_world into dev fixing conflicts if any
push dev
This system will teach students fundamentals for keeping a fresh version of the repo whenever they work, how to deal with merge conflicts, and how to coordinate tasks with other developers to avoid overlap. Pull-requests and other concepts can be introduced to students/projects that understand fundamentals later.
If you go with a pull-requests system. Then someone is responsible for approving them. So depending on the project, that's desirable or not.
That's my suggestion at least.