#37 Replacement of #28: Add contribution guideline

병합
samuelgarcia NeuralEnsemble/contribution_guide 에서 NeuralEnsemble/master 로 1 commits 를 머지했습니다 3 년 전
sprenger 코멘트됨, 3 년 전

This PR is an updated version of #28, which was corrupted during the implementation of #29. This PR solves #27.

In the proposed contribution guide contributors need to be added as collaborators to the repository to be able to create branches in the repository itself instead of a fork. This is necessary since git-annex content is not copied between a fork and the main repository when a PR is merged. Adding contributors as collaborators has further implications since the permission scheme in gin is very coarse:

  • Collaborators can merge PRs -> We should make it clear that is is not advised.
  • Collaborators can push to existing branches -> We should make all base branches (master, git-annex, synced/master, synced/git-annex protected from pushes and force-pushes (allowing changes only via PRs)

Furthermore after merging a PR, admins should remove the source branches <my feature> and synced/<my feature>, e.g. via gin git push <remote> --delete <branch>.

Also note, that gin get fetches all git objects existing in all branches in the repo. This implies, that one non-annex branch with large files can cause the whole repository to take a long time for downloading, since also the content of that branch is downloaded. Deleting the respective branch resolves the issue as the data is deleted from the repository. -> We need to monitor existing branches for redundant files.

This PR is an updated version of #28, which was corrupted during the implementation of #29. This PR solves #27. In the proposed contribution guide contributors need to be added as collaborators to the repository to be able to create branches in the repository itself instead of a fork. This is necessary since git-annex content is not copied between a fork and the main repository when a PR is merged. Adding contributors as collaborators has further implications since the permission scheme in gin is very coarse: - Collaborators can merge PRs -> We should make it clear that is is not advised. - Collaborators can push to existing branches -> We should make all base branches (`master`, `git-annex`, `synced/master`, `synced/git-annex` protected from pushes and force-pushes (allowing changes only via PRs) Furthermore after merging a PR, admins should remove the source branches `<my feature>` and `synced/<my feature>`, e.g. via `gin git push <remote> --delete <branch>`. Also note, that `gin get` fetches all git objects existing in all branches in the repo. This implies, that one non-annex branch with large files can cause the whole repository to take a long time for downloading, since also the content of that branch is downloaded. Deleting the respective branch resolves the issue as the data is deleted from the repository. -> We need to monitor existing branches for redundant files.
sprenger 코멘트됨, 3 년 전
소유자

@apdavison & @samuelgarcia: Can you please have a quick look at this and decide if in principle this way of handling contributions is acceptable for you (making contributors collaborators) or if you see any other way on how to implement this more nicely? I think this is a rather urgent discussion as we want people to contribute to this repo.

@apdavison & @samuelgarcia: Can you please have a quick look at this and decide if in principle this way of handling contributions is acceptable for you (making contributors collaborators) or if you see any other way on how to implement this more nicely? I think this is a rather urgent discussion as we want people to contribute to this repo.
Samuel Garcia 코멘트됨, 3 년 전
소유자

I am totally OK with this new way. I am trying it now with openephysbinray. Tell if it is ok.

I am totally OK with this new way. I am trying it now with openephysbinray. Tell if it is ok.
sprenger 코멘트됨, 3 년 전
소유자

@samuelgarcia I think this worked well for the openephys example. Do you want to add a paragraph that if people only want to contribute once it is also ok to provide the files outside of gin and we take care of the integration?

@samuelgarcia I think this worked well for the openephys example. Do you want to add a paragraph that if people only want to contribute once it is also ok to provide the files outside of gin and we take care of the integration?
이 풀리퀘스트가 성공적으로 머지되었습니다!
로그인하여 이 대화에 참여
레이블 없음
마일스톤 없음
담당자 없음
참여자 2명
로딩중...
취소
저장
아직 콘텐츠가 없습니다.