Hi - I haven’t had the time yet to read through this whole post, but one thing I have noticed is that before the migration, I used to get automatically added to the nosy list of Windows issues. While this wasn’t ideal (there’s a lot of Windows issues I don’t know much about ) it did give me some visibility of what was going on with issues.
Since the migration, I seem to be getting essentially no issue emails (unless they are being caught by my “github PRs” filter). Did the auto-nosy feature get lost in the transition (which would be auto-subscribing in Github terms, I guess)? And if so, is there any plan to get something like that back? I note that the “Noticing new issues/PRs” section only really suggests approaches that require people to actively log onto github, or only apply to PRs.
I’m not aware of any way for me to subscribe to “types” of issues in Github - I can either manually subscribe to individual issues (which is fine for following things I have found out about, but no use for finding out about issues in the first place) or I can subscribe to the repo (which is unworkable, because the traffic is way too high, and also offers me no way to distinguish in the emails I receive between “stuff I just want to be aware of” and “stuff I’m actively interested in”). If I could subscribe to individual labels (ideally with the label being identifiable from the email, so that I can filter on it) that would be ideal, but I don’t think that’s possible. Equally, a feed of just the first post on each issue (but not follow-up comments) would be useful, but again I don’t think github supports this.
It’s not a huge deal - in the worst case, I’ll simply accept that I can no longer get emails for issues unless I manually subscribe to them - but given that this means I’ll end up being less active, I thought it would be worth mentioning the issues I face (in the spirit of “Retaining devs after a migration”). I’m a relatively active user of github, but my entry point on other projects is almost entirely email notifications - I don’t actively scan the website for issues on any project I participate in.
: Is there a way to separate issue emails from PR emails in a filter? Does Github mark the two differently?
Excellent! I with I could add a to every section, but I cannot, so I add only one .
I think the weekly report of new issues plus a custom filter (open issues with 0 comments) would solve the most of the problem.
Is it possible to create personalized list of issues? For example I would like to create lists related to zipfile or json. It is not worth to add global label for every module/topic, and search with specific terms could give unrelated issue or do not give all related issue, so I would like to manage the lists manually and to work on them when I have a time and an appropriate mood. It would also be helpful to distinguish issues which I want to follow (but not going to resolve it myself) from issues which I am going to resolve myself (some time in future), from issues on which I am currently working, and from issues in which I just left some comment.
You are right. The untriaged label would be useful in case someone replies to the issue while the issue is still untriaged, but if the triagers manage to go through all the new issues regardless of the number of replies, then it might not be needed.
If you think the project might be useful for other devs, you can also create it on the Python org: this way it will be visible in the sidebar and will help you and others discover related issues. I also recommend using the new beta projects (you can ping me if you need help setting them up).
Ah, cool. It’s possible I did get a notification, but I generally ignore “windows team” PR review requests, because I typically don’t have much useful to add (I think the CODEOWNERS triggers review requests on a big bunch of stuff that’s only marginally Windows related). As I said, I’ve yet to work out how to split issue and PR mails (or better still, set things up so that I get issue notifications, but don’t get PR notifications unless I’m explicitly @-mentioned by name).
The remaining thing missing from Roundup for me is therefore getting notified on issues that are tagged as “Windows”. If I understand correctly, users can’t set a “Component” on new issues the way they could on Roundup, so that basically comes back to label subscriptions combined with a reliance on triagers to add the label. So that’s on me to do some work to set things up how I want.
lol, I’d forgotten that existed, because the auto-nosy was sufficient for me on Roundup (and if I recall, the number of emails if I subscribe to all new bugs was too high). I’ll take a look at that again.
By the way, I should say thanks for all the work that’s gone into this. I probably sound rather negative, but honestly I’m mostly just trying to understand all the new options I have (as I say, I use github a lot, but only on projects much smaller than CPython, where “subscribe to everything and handle the flow in my email client” is sufficient, so I’m having to learn how to handle larger scale problems this time). So I appreciate your patience helping us all get familiar with the new setup.
As has been clear in the responses (which seem to have focused on the mechanics of the migration rather than concerns about issue/PR triage/review/etc.), this thread is too unfocused to be useful. Irit’s idea was the better one: post threads focused on one particular idea, and keep the threads apart in time, to keep the discussion focused. For example, let’s start here.
I didn’t mention this here (only on Discord), but I wanted to use this as meta issue to gather some initial feedback on the specific suggestions and then turn actionable items into issues on the core-worflow, bedevere, cpython, and other repos after some consensus is reached. Having other threads for specific problems is fine too if they need more discussion (in fact, I linked to @irit’s thread from one of the problems above).
Currently it triggers for everything in PC/, PCbuild/, Tools/msi, and Tools/nuget (see the CODEOWNERS file)
This is correct. Relying on reporters is tricky, since they might classify issues incorrectly. For example, we could create templates with a drop down where the user can select their operating system, and while the information is useful, that doesn’t necessarily mean that the issue is Window-specific.
Understanding the problems that people are facing so that we can address them is one of the things I wanted to accomplish, and negative feedback is much more useful towards that than positive one
I like a lot of these ideas, but I’m not sure about this one:
I’m not 100% clear on what removing an untriaged label would signify. As a triager, I read quite a lot of newly opened issues. I’ll close obviously spammy issues, as well as issues that obviously need a lot of discussion on this site or python-ideas before an issue should be opened. I’ll also do my best to add relevant labels.
But at the end of the day, I’m not an expert on the vast majority of the code in the CPython repository. For many (most?) issues, I don’t feel confident to say definitively, “Yes, this is definitely a legitimate bug report that deserves a core developer’s time”. So I don’t think I, personally, would be removing the untriaged label very often at all, even though I do a fair bit of triage work.
If you feel that the issue needs more triaging, then leaving the label after a partial triaging is fine.
If we decide to add this label, we should also agree on what we consider “triaged”: is it just closing clearly invalid issues and adding the relevant labels to the valid ones, or should it also include approving the issue and/or replying to the author?
Isn’t this kinda the same as was discussed on the summit: adding an acknowledged label on bugreports that were confirmed (reproducible and it’s a bug in CPython, not in the environment) and feature request that were considered reasonable? Adding an an ack label or removing an untriaged label has, in practice, the same effect.
They share some similarities but the goal and target is different:
the purpose of untriaged is to indicate to other triagers that they should look at the issue and triage it, so that it doesn’t go unnoticed.
the purpose of acknowledged (or the initially proposed accepted) is to inform the author that their issue has been seen and/or accepted.
For example if I see an untriaged issue about asyncio and I can reproduce the behavior on 3.10/main, I might add the type-bug, stdlib, expert-asyncio, 3.10, 3.11 labels, and remove the untriaged label. This will notify the asyncio expert and they (hopefully) will take it from there, either by fixing the issue or by closing it if it turns out the behavior is expected/intentional.
acknowledged/accepted might also create expectations in the author, and has the disadvantage that most open issues will end up with an extra label. Searching for -label:acknowledge might also bring up old/triaged issues that are awaiting for more information, an expert opinion, or are still being discussed, making it more difficult to find untriaged issues.
I don’t feel like I have a clear idea of what it means for an issue to be “fully triaged”, and even if we come up with a common definition, it’s going to be a fairly broad definition. That means I’d end up having to study an issue in detail to work at what stage of triage it is – which is basically what I do already, so I’m not sure having the label would change much.
I prefer the idea of having more informative labels, like reproduced (for bugs) or accepted (for features), which give some information about what specific triaging steps have been taken. triaged/untriaged feels too vague to be useful (from my perspective )
What I mean is pretty much to classify the issue by adding all the applicable labels and possibly @mentioning relevant people, or close the issue if it’s clearly invalid. Maybe unclassified is better?
This can generally be done rather quickly, even without fully understand the problem. After the issue has been classified, the untriaged label can be removed and an “expert” can pick it up from there. You may also decide to spend some more time investigating the issue yourself, looking at the code, trying to come up with solutions, and possibly even proposing a PR and fixing it.
The goal of this label is just to provide a convenient way for triagers to know which issues they should look at without having to actively chase new issues, in order to make sure that every issue gets at least seen and classified. In general we would only have a few recent issues with the untriaged label. This is assuming we need a label to ensure that issues don’t go unnoticed in the first place.
This was pretty much the role of stage field on bpo, but it was decided to remove it.
Interesting timing on this discussion. I just posted this blog post over the weekend, about a system I set up for our Python tooling repos at Microsoft. I’d be happy to take feedback and enhancement requests here if you think this might be useful to you too.