search

archivematica / Issues

Issues repository for the Archivematica project
GNU Affero General Public License v3.0
16 stars 1 forks source link

Problem: fork-based git workflow for Archivematica contributors is not well documented #186

Open jrwdunham opened 6 years ago

jrwdunham commented 6 years ago

Please describe the problem you'd like to be solved.

It is not clear, both for Artefactual-external and Artefactual-internal contributors to Archivematica and related projects, how pull requests from forked repositories can be created and kept up-to-date with the main Archivematica repositories. It is also not clear whether development branches should ever be pushed to https://github.com/artefactual/archivematica or if all contributors

Describe the solution you'd like to see implemented.

I would like to see documentation describing how to:

  1. create a fork of Archivematica (AM),
  2. push a dev branch to the fork,
  3. create a PR against AM from the AM fork,
  4. request and receive code review (CR),
  5. rebase (i.e., pull upstream changes into the fork branch, if necessary)
  6. merge the PR (if you are an authorized committer) or close it, as necessary.

I would also like to see a discussion of the pros and cons of requiring Artefactual-internal developers to follow the same procedure that external developers must follow, i.e., that outlined above. This discussion could take the form of an ADR/Proposal in the proposed "Proposals" repository.

Describe alternatives you've considered.

Continue to help external contributors do the above by walking them through the process, if they need such assistance. However, this is inefficient.

Additional context

A contributor from UofE recently ran into this issue and this revealed that it would be nice to have documentation to handle this.

For Artefactual use: Please make sure these steps are taken before moving this issue from Review to Verified in Waffle:

joel-simpson commented 6 years ago

I think this is a great idea - both to document the process for forked repositories, but also to consider standardizing on one approach that works for both Artefactual staff contributors as well as contributors from other organisations (or individuals). If will be much easier for Artefactual staff to explain the process and support external contributors if they are using the same process on a regular basis.

It might be worth noting the docs repo does a good job of providing documentation for both external vs. Artefactual contributors. (that distinction might make more sense for docs contributions)