Right now we have multiple labels called expert-SOMETHING to attach issues to known expertise fields. See Labels · python/cpython · GitHub
But, the problem is that expert- prefix is not just about the field itself. In my opinion, it also indicates a complexity level. People might assume that the label is complex and might just skip working on it. So, we might hurt new contributors with this naming pattern.
I think we should rename all existing labels with expert- prefix to use something different. My personal favourite is topic-, we use it for mypy. It serves us well, see: Labels · python/mypy · GitHub
I am going to create a poll with some other names as alternatives.
topic-
field-
related-to-
component-
expert- (do not change the existing one)
0voters
What happens next?
In a week or two we can close this poll
Someone with the required permissions will update the existing labels (if needed)
I am not convinced that there is a problem. How many beginners have actually said “I did not work on issue x because 'expert intimidated me”? Hence i voted for ‘leave alone’ (for now).
What does the devguide currently say is the purpose of the label? Depending on the answer, I might suggest ‘ex’ (intentionally ambiguous) or ‘cat’ (for category, and many core-devs favorite pet).
‘topic’ changes the sort order. That could be considered good or bad. Might we prefer having the group first or last, especially as the number of such labels increases? I liked the idea of an emoji, but agree with the typing problem. So use a visible ascii symbol: ‘!’ sorts first, ‘~’ sorts last.
Link 2, about draft PRs, seems irrelevant.
I think having a poll before discussion was premature.
I think the expert-... make sense when being applied to a PR, to indicate this PR will require review from someone with more experience in a certain topic. But we also already have codeowners who are considered experts in specific area who will get review requests.
When applied to issues, I can see how some people may find the expert-... label intimidating, so I agree that the “complexity” of the issue shouldn’t be attached to the topic/category.
As CPython core devs, we generally have a strong prior against changing things for the sake of changing things. This is a healthy attitude to take towards changes in our codebase: it’s important for the standard library to be relatively stable. Moreover, the risk of accidentally breaking somebody’s code though a seemingly innocuous change is always large.
However, that’s a bad prior to have when considering this proposal, in my opinion. There’s no proposal to change any code here, and there’s no risk to our external users. Rather than asking “Is this change really necessary?”, we should instead ask “Are these the names we would choose if we were designing the labels from scratch?”
For me, the answer to this question is very clearly “No”. The only reason these labels have the expert-* prefix is because those were the names these classifications had on bugs.python.org. The names were simply carried over when we transitioned from BPO to GitHub. I think a natural reading of the word “expert” in this context implies “You need to have some level of expertise to contribute to an issue with this label”, and that’s not an implication I want the label to have (at least not for the area I maintain, typing).
I don’t think it should be a requirement that we see complaints from potential contributors in order to consider making this change. Such complaints would be unlikely to be made anyway, as potential contributors put off from contributing would probably simply not participate at all.
If you set up projects automation (using the auto-add workflow from within the project), you might have to update the workflow to use the new label, since it doesn’t seem to update automatically. The auto-add workflow is somewhat new, so I don’t expect many projects to use it.
