-
Notifications
You must be signed in to change notification settings - Fork 4
feat: add a bunch of organization-wide labels #61
feat: add a bunch of organization-wide labels #61
Conversation
0496f6d
to
478c5fc
Compare
FYI @e0d |
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.
These are wonderful, and the labels.yml
file is extremely easy to read. This makes me super happy!
I left a few comments in there, mostly hoping to start a few conversations. Even if none of the comments I made are addressed I'm happy to say !
0d7faeb
to
1136d19
Compare
migrate/labels.yml
Outdated
|
||
- name: "help wanted" | ||
color: "54976d" # fenway green | ||
description: "Ready to be picked up by anyone in the community" |
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.
Who will be adding this label to issues? Sort of by default, all issues are "help wanted". Is there some specific kind of ready this is meant to indicate other than it's an open issue?
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.
@nedbat To me, the help wanted
label is meant to answer the question "I'd like to help with this group/project, what should I work on next?" Consider it a superset of good first issue
.
Open issues that wouldn't warrant a help wanted
labels are:
- a "draft" issue; one that hasn't been refined well, maybe something you wrote up quickly with the intent of fleshing out later, like this one.
- issues that require special permissions, like Axim requests, or certain WG tickets like this one.
- ones that require special context like this one.
- issues with a high technical barrier to entry.
- issues that are part of an actively funded project (ie, someone is already being paid to do it).
- issues that already have intended assignees, like this one.
Who will be adding this label to issues?
Anyone! I'll be using it for my working group, and I'll encourage other WG leads to as well.
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.
This sort of guidance will be good to have somewhere. This file is not discoverable, but I'm not sure where else to put it.
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.
OK, maybe this is something we could add to maintainer playbooks or contribution guides on docs.openedx.org.
That said, I am hoping that the labels can be as self-explanatory as possible. We can't assume potential new contributors will be reading docs.openedx.org, so the more obvious we can make ourselves to the outside world with the tools GitHub gives us, the better.
Is it not reasonably clear what help wanted
means?
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.
My only concern about "help wanted" is the interpretation that if the label isn't on a PR, then we don't want or need help with it.
My suggestion about putting your guidelines somewhere was not so that new contributors would find them, but so that we who are labelling issues would have a common understanding of the labels.
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.
My suggestion about putting your guidelines somewhere was not so that new contributors would find them, but so that we who are labelling issues would have a common understanding of the labels.
That makes sense. I think the maintainership playbooks would be a good home for these docs, then.
Labels that I have used across projects at edX:
|
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.
This looks great @kdmccormick, it'll be great to have a standard set of org-wide labels.
1136d19
to
f96ddbd
Compare
f96ddbd
to
9cf4185
Compare
Thank @wittjeff , I went and added |
Comments are addressed; I think this is ready to go. Please let me know by EOD tomorrow (Thurs) if you have any concerns! |
Dry-run output: https://gist.github.com/kdmccormick/ae8d40dd2362df440161f66a74342dae Will merge and apply once I've confirmed that "feat!: don't sync any repo labels" in openedx-webhooks-data (private) are deployed to the bot. |
Applying now... |
Almost done, but hit GitHub's rate limit. Will finish later. |
Description
This populates labels.yml with a list of labels that will be synced across the openedx GitHub organization. The labels will be synced by Axim using repo_checks.py.
The labels' spelling, color, and description will be made consistent. If a repo has an existing label with similar spelling (that is: ignoring capitalization, emoji, spaces, and special characters) then the label will be edited in-place instead of created anew. So, we shouldn't have a bunch of old-spelling labels lying around when this is done.
The proposed labels.yml is based on the comments on this wiki page.
Considerations
Blocking work
This PR is based on the work from #60, which actually implements the labels.yml syncing. If you want to review the implementation rather than the labels, refer to that PR.
Also, before applying these labels to the org, we need to ensure that:
DEPR
label to repos.Followup work
Once
core contributor
is added to every repo, we can wrap up: openedx/openedx-webhooks#227No emoji
I decided not to include emoji in the labels. My driving motivation is that searches/filters become harder to type and harder to read when emoji are involved. Consider:
versus
I could be persuaded otherwise; what's most important to me is that we're consistent :)
Things to keep in mind...