the-blue-alliance github issue triage

[Greg Stanton Marra]

Blockquoting @Brennon Brimhall from #dev-web on slack:

I figured I'd spend some time during the holidays to work on some TBA stuff, and I noticed some interesting trends as I dug through the issue tracker. I've included some suggestions (in italics to help visually distinguish it from the data). I'd love some feedback, since I definitely have a narrow perspective here.There are 279 open issues on the web repo. However, only 42 of those open issues were updated in the last year. The following issues were updated in the given years:

• 2019: 42

• 2018: 87

• 2017: 68

• 2016: 57

• 2015: 10

• 2014: 3

• 2013: 10

• 2012: 1

• 2011: 1

Similarly, we have 22 open pull requests from a few different years:

• 2019: 7 (4 are drafts)

• 2018: 8

• 2017: 4

• 2016: 2

• 2015: 1

Is there a way we can clean out some of these older items? If something hasn't been updated since 2017 (the last season in memory for most high school seniors), I think that would be a good candidate for automatic closing.There are 19 different labels we put on issues. We have the following numbers of open issues for each label:

• Accounts: 1

• API: 6

• Bug: 8

• Data: 15

• dependencies: 0

• Enhancement: 42

• GameDay: 8

• GDCV: 5

• Hackathon: 3

• Help Wanted: 36

• in progress: 4

• javascript: 0

• Media: 3

• myTBA: 1

• python: 0

• TBANS: 7

• Tech Debt: 1

• Tech Lead Wanted: 0

• URGENT: 1

Is there a way we can clear out the "URGENT" label? The one issue there hasn't been updated since October 2016. The issue describes a pretty nasty bug that could cause us to lose data, but it's unclear if it's been fixed. Is there a reason to keep "dependencies", "javascript", and "Tech Lead Wanted" around?We have a few different milestones in the tracker right now: Offseason 2017, Competition Season 2018, APIv3, and Championship 2018.It looks like most of these milestones could be updated: Offseason 2017, Competition Season 2018, and Championship 2018 have all passed long ago. We shipped APIv3 and have removed APIv2, so that should probably be updated.Do we have a focus for what we want to do for 2020?

Thank you for the audit of the open issues!

Building on Brennon's suggestions, we could:

1. Minimize open issue complexity – Make things more friendly for noobs to get going
1. Establish a 2 Year Bug SLA. Anyone should feel empowered to close an issue that has been open for more than 2 years that is tracking a feature request or minor bug. Bugs that lead to incorrect data, or are tracking incorrect data, should remain open. In January 2020, that means anything from December 2017 or earlier can be closed.
2. Deprecate Stale Tags – Tags with 0 issues should be deleted
3. Deprecate Past Milestones – We should remove milestones tracking the past. That's probably all current milestones :)
2. Make it east for new people – Someone with a spare evening should be able to come to our GitHub, and know how to get going
1. Maintain Tags for "Help Wanted" – We should have a few issues that are user-visible features that are easy to get going with, to help new people.
2. Keep Good Docs – This is always an uphill battle, but our docs should always be up to date at describing how to get a dev environment running, and making a simple change

@Brennon Brimhall , do you see anything else we should be doing here? Would you want to take a pass through the issues to clean things up?

-Greg

[Brennon Brimhall]

As long as we document the new SLA and actually prune the old stuff, I think that's good enough for now.  I think the items you've listed under #2 are going to be significantly more work. 

On Sunday, December 29, 2019 at 7:56:17 PM UTC-7, Greg Marra wrote:

Blockquoting ...@Brennon Brimhall from #dev-web on slack:

...@Brennon Brimhall , do you see anything else we should be doing here? Would you want to take a pass through the issues to clean things up?

-Greg

[Zach Orr]

What's the reasoning for closing old bugs? I think if we can confirm bugs are fixed or no longer occurring they're worth closing - otherwise, don't we just lose visibility on bugs?

--
You received this message because you are subscribed to the Google Groups "thebluealliance-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thebluealliance-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thebluealliance-developers/024cd023-1df9-4921-bfe7-8c06522ff3a6%40googlegroups.com.

--

~Zach

[Greg Stanton Marra]

@Zach Orr , thinking about this more, there's probably some balance. A goal is to make it easier to find signal in noise, but we shouldn't lose sight of important bugs to fix. However, if we haven't encountered a bug for 3 years, how important is it to keep track of, vs opening a new issue when someone sees it again?

Two different cases

1. CLOSE old feature request, like #1248, Add Random Match on Homepage
   
2. CLOSE? old bugs, like #1637, IndexError: list index out of range
   

To view this discussion on the web visit https://groups.google.com/d/msgid/thebluealliance-developers/CADDXcOFs1UhA875u3JrGbcv9WodwKd8C6q5UN_%3DYk2E%2BssiZpQ%40mail.gmail.com.

[Brennon Brimhall]

Good points. Maybe the best solution here is to just go through each outstanding issue manually. I’m happy to put together a list of issues I’d recommend closing, if that would be helpful.

[Greg Stanton Marra]

@Brennon Brimhall , why don't you feel free to close any old feature requests as a first pass – we can always reopen anything.

Want to apply a label "maybe close" to old bugs you think look unlikely to need to be tracked?

On Tue, Dec 31, 2019 at 12:30 PM Brennon Brimhall <brennon...@gmail.com> wrote:

Good points.  Maybe the best solution here is to just go through each outstanding issue manually.  I’m happy to put together a list of issues I’d recommend closing, if that would be helpful.

--
You received this message because you are subscribed to the Google Groups "thebluealliance-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thebluealliance-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/thebluealliance-developers/cb0fd236-0fdd-4e9a-a435-5817d7b37540%40googlegroups.com.

[Brennon Brimhall]

Pretty sure I can't close anything or apply labels, as I'm not a member of the GitHub org.  Would you like to give me access?  If you'd prefer not to, I can put them in email format here or on Slack.

[Zach Orr]

Feel free to suggest a list of issues in the Slack - I promise someone will take a pass at them 😇

Sent from my iPhone

On Dec 31, 2019, at 2:56 PM, Brennon Brimhall <brennon...@gmail.com> wrote:



Pretty sure I can't close anything or apply labels, as I'm not a member of the GitHub org.  Would you like to give me access?  If you'd prefer not to, I can put them in email format here or on Slack.

--

You received this message because you are subscribed to the Google Groups "thebluealliance-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thebluealliance-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/thebluealliance-developers/64f5119f-0499-444a-a55c-e0f58b8e00b4%40googlegroups.com.

[Brennon Brimhall]

I just went through everything pre-2016: https://the-blue-alliance.slack.com/archives/C15SUFL92/p1577825804027300?thread_ts=1577385296.010100&cid=C15SUFL92

I'll get around to the rest of them soon (ideally before kickoff).