-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add repository guidelines and list of repositories #105
Conversation
6839fc8
to
5b919bb
Compare
bedece9
to
f1cada2
Compare
f1cada2
to
f28535d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for putting this together! I think the broad strokes of this make sense. I have some bits of feedback scattered through the proposal, see the individual comments below.
I was also trying to consider the personas of who may be involved in this process in order to understand whether the process makes sense for those people.
One common case may be that there is an upstream library which we want to use with a few tweaks. We temporarily fork the repo for expedience while we figure out the long term solution upstream. As a committer, I may click the fork button and start developing on a branch. That's about it. Obviously we need to ensure that the license is compatible. So from that perspective, are the issue templates useful for that persona? Should we skip the process? What value does the process provide to the personas involved in that workflow?
Another example may be that someone wants to donate some software to the project. For that, I think it's useful to have an easy-to-find issue template that can help them to initiate the discussion and that would serve as the tracking issue for the process. I get the sense that the process currently is more tailored towards this case, though I think that in practice this is relatively rare. That said, even if it only occasionally helps contributors to drive discussions around new repositories, then I think that would make the issue templates useful as tools to push the project in a positive direction.
Maybe there are other personas that we're considering, and perhaps by perusing through some of the existing repos we could identify others. I would welcome highlighting any of those if they come to mind.
Signed-off-by: Katie Struthers <99215338+katiestruthers@users.noreply.github.com>
Signed-off-by: Katie Struthers <99215338+katiestruthers@users.noreply.github.com>
Signed-off-by: Katie Struthers <99215338+katiestruthers@users.noreply.github.com>
Signed-off-by: Katie Struthers <99215338+katiestruthers@users.noreply.github.com>
Signed-off-by: Katie Struthers <99215338+katiestruthers@users.noreply.github.com>
Co-authored-by: Bill Mulligan <billmulligan516@gmail.com> Signed-off-by: Katie Struthers <99215338+katiestruthers@users.noreply.github.com>
Signed-off-by: Katie Struthers <99215338+katiestruthers@users.noreply.github.com>
@joestringer what is the current process for forking something into Cilium? Is it something any committer can do immediately or do they ping you/andre in slack? I don't think we need to change the process, maybe just document it so it is easier for people to follow |
@xmulligan generally speaking I think that folks reach out to Andre/I and we create the repo. I'm not sure whether committers have the ability to fork repos into Cilium - perhaps you could try it out and see whether that option is available to you? |
Co-authored-by: Joe Stringer <joestringernz@gmail.com> Signed-off-by: Katie Struthers <99215338+katiestruthers@users.noreply.github.com>
Signed-off-by: Katie Struthers <99215338+katiestruthers@users.noreply.github.com>
@joestringer yes it seems I can just fork into Cilium. |
Hi @joestringer - anything additional to add for the forks? It sounds like we are leaning towards writing a forks-specific process instead of using the same issue template for creating a new repo. I could make a sub-section under Addition for forks, something along the lines of - "To create a new fork, reach out to one of the Cilium Committers with an explanation of why it would be helpful for your work within the project." The committer would then do the license check and add it to REPOSITORIES.md. |
Maybe I was overthinking it earlier with considering the process for forks. Ultimately if someone has the power to create a fork, it's quite possible they'll just go ahead and do it. If someone doesn't have the power, they can use the same "create a repo" issue template and describe what they're trying to achieve, and committers will see the PR on the community repo and respond. In the end, as long as the requirements laid out in the github issue are followed, it's not a big deal how we make the forks happen. We can always just document that the good path is to file an issue using that same template, that way the process is the same for any repo creation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO this looks like a very reasonable proposal, seems ready to draw attention from a wider group of committers. Do you agree @xmulligan ?
Yes, let me drop it in the committers slack channel to see if there are any further comments |
Signed-off-by: Katie Struthers <99215338+katiestruthers@users.noreply.github.com>
Thanks for working on this @katiestruthers , merged. |
This PR adds the following four files:
1. REPOSITORY-GUIDELINES.md
2. REPOSITORIES.md
3. .github/new-repository.yaml
4. .github/change-of-scope.yaml
Fixes: #27, #82