Aspnetcore: Discussion for: Using the "Home" repo for issue management of other repos

[Eilon]

This is a discussion issue for: https://github.com/aspnet/Announcements/issues/283

[kevinchalet]

Terrible idea, IMHO, as it will make the Home repo so noisy that virtually nobody will want to watch it.

Having tickets opened on dedicated repos (e.g aspnet/Security) allows receiving notifications for topics you're potentially interested in. With your new approach, it's no longer possible...

[natemcmaster]

Does anyone know if there is a good way to filter GitHub notifications by tags or by comments from specific users or teams? For me, GitHub notifications are already useless, even before this change.

[Eilon]

@PinpointTownes thanks for the feedback, we're aware of that limitation and we hope to come up with some solutions to that. For example, we can create GitHub teams and let anyone (even non-ASP.NET/EF team members) add themselves to the teams, and a bot would notify all team members of new issues in that area.

We started out with some of the lower-trafficked repos first because we figured it would be less of a problem, while we figure out how to overcome the limitations.

[davidpeden3]

Couldn't agree more. This change is a huge mistake. And the bot that migrated the issues doesn't update pull request links correctly. See https://github.com/aspnet/Home/issues/2496 (second to last comment containing a link to #46 which should've pointed to https://github.com/aspnet/Proxy/pull/46).

[Eilon]

@davidpeden3 ah yes that is indeed not intended. Granted, that type of issue has already been problematic before because even today we often have to move issues between repos and the links can get broken. I'll try to fix this in the issue mover.

[kevinchalet]

@Eilon that sounds super convoluted.

BTW, is there even a pro for adopting this change (e.g does it make triage easier?) or is it one of those arbitrary decisions you guys like to take from time to time? :sweat_smile:

[davidpeden3]

@Eilon thank you

[Eilon]

@PinpointTownes we wanted to make things clearer with:

1. Where to log bugs? Answer: Home repo. (Anyone who has followed the repos here has seen us move bugs back and forth anyway.)
2. Where to find bugs? Answer: Home repo. (Even for us, trying to find where a bug was logged is a tedious chore.)
3. Easier for the team to triage bugs, including consistency with milestones and labels.
4. Ability to use GitHub Projects that cover issues from multiple repos. Today GitHub projects can be public only if they are within a repo. We want to share with everyone our overall planning and linking multiple issues from multiple repos and that isn't possible. By consolidation issues in one issue tracker, we can share more about our future plans.

[tugberkugurlu]

Ability to use GitHub Projects that cover issues from multiple repos.

I believe you can already do that across repos with org level project boards, no? https://github.com/blog/2272-introducing-projects-for-organizations

[Eilon]

@tugberkugurlu unfortunately that doesn't work for non-members. Only members of the org can see org-level projects.

[Zoxive]

So when I want to open an Issue who is going to triage all new issues to assign the right tags so the right team can be notified of them? It seems like an added delay/another user in the process.

Also the issue template for this repo still says

To address your issues more quickly, please open the issue in the most appropriate repository. 
These are some of the most common repos:
...

Other than that, I like the _idea_ of one location so we can see combined milestones/etc.

[Daniel15]

Would you ever consider doing the same thing for the code, and using a single repo for the whole of ASP.NET? It'd make code navigation much easier, although I guess it does mean that people wouldn't be able to "watch" individual parts of the framework any more.

[natemcmaster]

Would you ever consider doing the same thing for the code, and using a single repo for the whole of ASP.NET?

@Daniel15 We've contemplated this idea several times over the last year. It would introduce big infrastructure problems that we're not prepared to solve. We have ideas for how it could work, but not enough bandwidth (or motivation) to implement them. The closest thing we have is https://github.com/aspnet/Universe, which collects many repos together as submodules. This takes ~30 minutes to compile on a fresh machine. It's only designed for CI builds, so it's not incremental.

[khellang]

Let me state just a few reasons why I think this is a terrible idea:

1. It makes the Home repo really noisy, especially when it comes to notifications. Thanks for the 1500+ new email notifications, BTW 😉
2. It makes it much harder to find specific issues because of the noise mentioned above.
3. Because all existing issues were "moved", it's now harder to track existing discussions, gather context and navigate cross-references.
4. Every pull request that wants to close an issue has to cross-reference issues using organization/repository#issue-number instead of just #issue-number.
5. Every issue that wants to reference a pull request needs to do the same as 4., only in reverse.
6. Instead of occasionally having to move issues, you now have to label every single issue that "belongs" to a different repository.
7. Embedded code snippets won't work anymore because the issues are in a different repository than the code.

That's just some things off the top of my head. I honestly think this will make things worse for both the team, contributors and the community at large 😢

I get that you don't _have to_ consult with the community before doing changes like these, but given you pride yourselves on ">60% of contributions come from the community", as @shanselman has mentioned several times, I think it's really weird that no "heads up" was given. If only to allow us to unsubscribe from the Home repo before the mail storm. Yet another huge decision that was made behind closed doors without any transparency 😞

[khellang]

Also, if you really want to keep all issues in the Home repo, you should close the issue trackers in all the other repositories instead of leaving a single issue stating "THIS ISSUE TRACKER IS CLOSED - use the Home repo issue tracker". People will still file issues as long as there's an open issue tracker, which will create more work for you folks 😉

[Daniel15]

Also, if you really want to keep all issues in the Home repo, you should close the issue trackers in all the other repositories instead of leaving a single issue stating "THIS ISSUE TRACKER IS CLOSED - use the Home repo issue tracker".

Note that GitHub does have an option to totally disable issue tracking per repo. However, this also blocks access to all existing issues, so any links to existing issues will also break! I have various comments like this in my code:

// Workaround for https://github.com/aspnet/Routing/issues/363
// Temporary hack to work around https://github.com/aspnet/Routing/issues/391

and I'm sure I'm not the only one. For that reason, please don't disable the issue tracker for these repos!

A single "this tracker is closed" issue along with a "this tracker is closed" issue template is probably sufficient.

[galvesribeiro]

~You can also block who can post issues to a particular repo IIRC~

[vcsjones]

You can also block who can post issues to a particular repo IIRC

That affects all interactions, including the ability to open PRs.

[Daniel15]

Yeah I don't think there's a setting specific to issues (at least, I've never seen it in any repositories)

[muqeet-khan]

FWIW, if you need to search repo specific issues. You will now need to do:

is:issue is:open label:repo:HttpAbstractions
or select the appropriate label
and not
is:issue is:open repo:HttpAbstractions

getting into a habit of label:repo:XYZ is going to need some getting used to. Don't think people will use the dropdown because people never seem to use them when they can type and also because there are just so many labels. Also, Why use colon? Is that a GitHub requirement?

[Eilon]

From @khellang :

Let me state just a few reasons why I think this is a terrible idea:

1. It makes the Home repo really noisy, especially when it comes to notifications. Thanks for the 1500+ new email notifications, BTW 😉

Agreed, this is unfortunate. Of course the initial migration causes the most noise.

1. It makes it much harder to find specific issues because of the noise mentioned above.

Hopefully GitHub's search, along with a label:XYZ query will mitigate that. Fortunately, GitHub has good UI for filtering by label.

1. Because all existing issues were "moved", it's now harder to track existing discussions, gather context and navigate cross-references.

I think this is just a near-term problem. Most issues are "new" issues so this problem will eventually solve itself.

1. Every pull request that wants to close an issue has to cross-reference issues using organization/repository#issue-number instead of just #issue-number.
2. Every issue that wants to reference a pull request needs to do the same as 4., only in reverse.

I believe this is a fairly minor issue. We rarely use GitHub's PR-auto-closes-the-bug feature anyway because we have to explicitly mark our issues as "Done," which assists in creating more meaningful release notes.

1. Instead of occasionally having to move issues, you now have to label every single issue that "belongs" to a different repository.

I think this is a small cost.

1. Embedded code snippets won't work anymore because the issues are in a different repository than the code.

That's just some things off the top of my head. I honestly think this will make things worse for both the team, contributors and the community at large 😢

Honestly we don't know how good it will be. One thing that makes me a bit more at ease with this plan is that we already considered all the concerns here, which tells me that we thought this through to a reasonable degree. But of course there will be more unknowns that we discover, and we'll have to figure out how to deal with them.

I get that you don't _have to_ consult with the community before doing changes like these, but given ">60% of contributions come from the community", as @shanselman has mentioned several times, I think it's really weird that no "heads up" was given. If only to allow us to unsubscribe from the Home repo before the mail storm. Yet another huge decision that was made behind closed doors without any transparency 😞

Tune in to today's ASP.NET Community Standup to hear additional thoughts from @DamianEdwards, me, and others about this.

---

Also, if you really want to keep all issues in the Home repo, you should close the issue trackers in all the other repositories instead of leaving a single issue stating "THIS ISSUE TRACKER IS CLOSED - use the Home repo issue tracker". People will still file issues as long as there's an open issue tracker, which will create more work for you folks 😉

As was mentioned by others, disabling the issue tracker for a repo is itself a very big hammer because it breaks all existing links.

[Eilon]

Another thing worth reminding everyone who read the announcement is this:

We are experimenting to try and use the Home repo's issue tracker to manage issues for multiple repos.

The key word here is experimenting.

We looked at the repo traffic of all the ASP.NET repos and started this experiment with the 20 lowest-traffic repos, so the immediate effect is relatively minimal. If this experiment fails, we will "undo" this change (it's not that hard with our dear new friend @aspnet-hello). If it succeeds, we'll continue moving more repos. But what we know for sure is that we'll learn from this and see what works and what doesn't.

Very few people have experience managing dozens of inter-related repos within an org, so this is a learning experience to see how we can manage this.

[aL3891]

Honestly we don't know how good it will be.

Isn't that an even bigger reason to give the community a heads up first?

We already considered all the concerns here

People who are not at Microsoft or have access to the same tools and meetings you have, might have different concerns and challenges than you when it comes to using these repos. If you only use yourselves as reference (if that's what you did) you're missing out on a large portion of the community.

For me personally and i suspect alot of other lurkers as well, it breaks the use of github notifications to track what issues i've read the updates on as the github notification view can only group by repo and afaik as i know, there is no way to search for "unread" issues using the label system. This means that i have no other option than scrolling though all the issues that are unread on the home repo, and matters are made even worse by the fact that the label is not shown in the unread view either.

tl;dr; lurking/scanning for updates is made significantly harder.

Of course there is an argument to be made that users like me are low value since we don't make many PRs or comments, but i think alot of people start getting in to contributing by first monitoring a repo that they are interesting in, and now that's alot more difficult. this also means that community members who want to help out others by answering simpler questions are also going to have a harder time.

[khellang]

Of course the initial migration causes the most noise.

Maybe _most_, but the noise will be constant. If I just wanted to follow Kestrel issues, I now (or when/if they're moved) have to watch the entire universe of ASP.NET issues, which means a significant amount of noise. And because notifications don't show labels, I have to guess which issues are Kestrel-related by looking at the title.

I watch (and contribute to) quite a few repositories that I find interesting and know the code base fairly well. From time to time, I'm able to answer questions and have the author close them without any need for team interaction. I'm hoping others do this as well. You'd think that would save you (if only a little) time, no? IMO, that's what community is about. This would become increasingly hard as "interesting" issues would be increasingly hard to spot in the noise. In my case, I usually "bail out" and press "mark all as read" when the unread count becomes too high.

Hopefully GitHub's search, along with a label:XYZ query will mitigate that. Fortunately, GitHub has good UI for filtering by label.

That's only if the team can keep up and label issues correctly. Currently Home has 1872 closed and 100 open, unlabelled issues :smile:

We rarely use GitHub's PR-auto-closes-the-bug feature anyway

OK, maybe not, but issues are cross-referenced constantly, so it's still a valid point. Contributors now have to use the long form or full URLs to cross-reference issues from PRs and vice versa.

[reduckted]

I recall a similar decision last year where one of the teams (I can't find it, but I think it was in the dotnet or aspnet organization) decided that all announcements would be closed immediately. There was a mass spamming from closing the existing issues. A discussion followed about why they were doing it, the community told them it was a bad idea, so they reverted their decision and reopened all the issues again (causing another mass spamming).

Very few people have experience managing dozens of inter-related repos within an org, so this is a learning experience to see how we can manage this.

You could have always asked here first. Maybe someone in the community has experience with this sort of thing and can provide some feedback instead of just going at it blindly.

[Eilon]

In today's ASP.NET Community Standup we discussed this topic starting at this time mark: https://youtu.be/_3EpZJxuFJw?t=2328

[Eilon]

@reduckted we did evaluate several options, including writing custom tools to help manage this. We in fact already use some custom tools, but even they have limitations.

Because of the number of unknowns, we decided to experiment by moving 20 of the lowest-traffic repo's issues to this issue tracker to see how it could work. We don't have a specific plan on when (or even if) to move issues from more repos to here. That's certainly the direction we're leaning in, but we are not committed to that.

[reduckted]

@Eilon Thanks for the link. I remembered too late and only caught about the last 10 minutes of the standup live.

I accept that the decision has been made, so let's try it out and see how it goes. If it works, great! If it doesn't work, then a different solution can be developed.

Having said that, here's my two cents on this situation:

1. GitHub just doesn't support management of large-scale projects. Like it was said in the standup, GitHub doesn't handle large projects well. At all. By using GitHub, you get the huge benefits of allowing the community to contribute :tada:, but on the downside, project management is pretty horrible. ¯\_(ツ)_/¯

2. There was no previous discussion about this change with the community. In the standup, someone mentioned that this was discussed back in December. Even if you were going to go ahead with it anyway, it might have been good to make an announcement about it before it was implemented.

3. It was mentioned in the standup that all of the problems that have already been raised in this thread are things that you've already thought about. That's awesome, but it would have been helpful (to us and to you) to mention that you've already thought about those problems and perhaps why you don't see them as blockers. I think that would have prevented a lot of the "panic" that was created from this announcement.

4. Perhaps there's a bit of confusion around how much the community is involved with the project. The community can report bugs, fix bugs, and make feature requests, plus there's the community standups, but sometimes the decision making that affects the community appears to be done behind closed doors (#2022 is one past issue that comes to mind).

5. Developers don't like change. Remember the backlash when the top-level menu text in Visual Studio was changed to uppercase? 😁

[gulbanana]

i really don’t like the idea of search-based filtering, as i frequently use github on a phone where the search feature is not available.

[TheSamsterZA]

@Eilon How long will this experiment run for before your team decides whether it was a good idea or not?

For the record, I personally do not like the idea. It just raises another barrier to contributions that we all know has made .NET Core as awesome as it is today (looking at you, Kestrel). :)

[Eilon]

@TheSamsterZA hard to say how long. It's only been a few weeks so far, and at least from where I'm sitting, it hasn't been too bad. But, this is a rather slow time of year, so we'll need to see how things look once the rate of incoming bugs picks up a bit.

[cwe1ss]

Why Github hasn’t introduced a proper notification system yet really is beyond me. There’s now so many huge projects managed by big corps and all of them have the same problem. And everyone’s just wasting time by building weird bots that don’t work properly anyway.

Why don’t you people unite and put more pressure on the Github team??

I think that e.g. a simple new watching-option called “Be notified of NEW conversations”, which would only send one mail per issue, would be a great first step. This mail should have a “Subscribe to this conversation” link to let people opt-in to all comments. This would allow people to still know about every topic that’s being discussed without having to filter out all the comments from all the topics one is not interested in.

I'm pretty sure that this lack of proper notifications is responsible for quite a few burn-outs in our industry. I was watching a few bigger projects because I was interested in certain areas and it drove me mad. The result was that I stopped watching almost everything which obviously reduced my involvement in OSS.

I will also not watch this repo with the current notification possibilities.

[davidfowl]

I’m not a fan either, now I wish GitHub had first class isssue moving.

[markusschaber]

I support the "Be notified of new conversations" idea, but I also suggest a "be notified of announcements" - where the project maintainers can explicitly label specific conversations / issues etc as "announcement", and a "be notified of new releases" option. :-)

[cwe1ss]

@markusschaber check out https://about.sibbell.com/ - it will send you emails whenever a new release is published on any of your starred/watched projects.

[markusschaber]

@cwe1ss Thanks, I'll try it out. :-)

[aspnet-hello]

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.