Can we start submitting pull requests (and rebase&merge them)?
Yes
additional checks
Waiting we have automatic testing, letās make sure not to include large files.
Next week, we will include more pull request checks (reject binary files, etc ā¦ see list here)
master branch protected
We should make master branch protected
I forgot to mention it, but yes the master branch is already protected.
Here is the current configuration for master branch:
[x] Require pull request reviews before merging
Required approving reviews: 1
[x] Dismiss stale pull request approvals when new commits are pushed
[ ] Require review from Code Owners
[ ] Restrict who can dismiss pull request reviews
[x] Require status checks to pass before merging
[ ] Require branches to be up to date before merging
Status checks found in the last week for this repository:
[x] CommitCheck
[ ] ci/circleci: build
[ ] Require signed commits
[x] Require linear history (Prevent merge commits from being pushed to matching branches. )
[ ] Include administrators (Enforce all configured restrictions above for administrators.)
[ ] Restrict who can push to matching branches
Rules applied to everyone including administrators
[ ] Allow force pushes
[ ] Allow deletions
merge button
Here are the settings for the " Merge button":
[ ] Allow merge commits
[ ] Allow squash merging
[x] Allow rebase merging
[x] Automatically delete head branches
Existing teams
Currently we have the following teams:
community: Now that we have discourse, I donāt think this is useful. It is also extra maintenance work.
slicer-core: members of this team have admin access to all repository of the Slicer organization.
slicer-website-maintainers: Useful to grant access to only UI/UX folks that are not developers.
localization: Since folks that could contribute translation may not be developer, we should keep this.
For reference, here are the current teams:
Proposal (updated):
Create a slicer-developer team having write access to: Slicer, ExtensionsIndex and forks
Restrict the number of members in the slicer-core team and change access to maintain. This team would have merge right on the master branch.
Create a slicer-admin team with admin access to all repos of the Slicer organization
I just pulled up Slicer github to look for something, and noticed all the stars were goneā¦ ouch!
Perhaps this has already been hashed out in depth, but FWIW, throwing away a strong github profile is unfortunate and might be detrimental ā users/contributors/granting organizations make a lot of decisions about project viability based on star count ā¦for better or worse. As one example, I think github star count helped to qualify Slicer for free discourse hosting, even though we were somewhat below their listed minimum count.
I guess that a motivation for creating the repo from scratch was to maintain issue number continuity from mantis, but I would suggest transferring the issues from mantis in to a āgithub mantis archiveā repo instead, which could then be cross-referenced (and the issue transfer seems to only be titles anywayā¦).
It may also be helpful to know that you can then you can move issues from the āgithub mantis archiveā to the ārealā Slicer repository as needed, maintaining a chain of history (github creates back and forward links), and avoiding the situation where someone will need to triage ~500 issues by going back to mantis (better to triage on-demand).
This would also avoid losing the pull-request history on the existing repo, which seems more valuable than title-only mantis issue numbers.
I just pulled up Slicer github to look for something, and noticed all the stars were goneā¦ ouch
Thanks for the feedback.
This was discussed and we proceeded knowingly. I am confident we will recover our stars
There were two main motivations for creating a new repo: (1) filtering history removing large data, the repo is now 5 times smaller, (2) migrating issues.
We will discuss this during the community meeting on Tuesday morning.
Fair enough, though it took 3+ years to get close to 900 stars. Iāll point out another example where it matters: the Chan-Zuckerberg Initiative EOSS grants are very focused on github metrics (I guess they consider itās a leading indicator of use/engagement, ahead of citations). If you do proceed with the current plan, I would suggest reaching out to github support to see if they can help in one way or another, but I wouldnāt count on that.
Just to note that you can do the filtering and force push over the entire history, which will have the same effect as starting from scratch.
If the issue migration included comments, cross-links, etc. then I could see a strong argument, but right now it seems the only benefit is retaining number continuity, at the cost of stars and valuable pull-request comment history.
Anyway, good luck w/ the change-over, and to everybody.
I may be naive here, but if we apply for such a grant where GitHub figures matter, then we can mention our recent transition. We have proof of our metrics, because everything is preserved in https://github.com/Slicer/SlicerGitSVNArchive. I donāt think people generally bother with unstarringā¦ Hopefully the people reviewing the applications can afford an extra click and see the nearly 900 stars, contributors, activity, etc.
The Admin Guide (2016) reports that there is no feature to make Mantis read-only. There is a threshold to make bugs read-only, so I set this threshold to NOBODY;
to everybody.