Cataclysm-dda: 1200+ unclosed issues, requires desperate measures

[Coolthulhu]

We don't have enough devs to afford shifting through loads of issues that often consist of vague "enhancements".

Here's an idea:
Automatically close all issues older than x months (3 or so) that lack a bounty or "Bug" label.

It's not like anyone is going to review those 2 year old suggestions, especially the vague ones that no one cares about.
Keeping those around doesn't help anyone. No one is going to review those old ideas to find something to implement. Old bug reports are very often outdated and yet not closed because they are not worth doing the mental bookkeeping (was it fixed? was it changed in a way that makes fix not necessary? is it relevant in any way?) necessary to close them.

Having a giant backlog of issues doesn't help any of those issues get reviewed.
In fact, it has the opposite effect - no one cares about issues on page 2+ except when pointing out duplicates (and duplicates only "count" up to page 5 or so - after that it's a fresh issue once again).

It is unfeasible to clean it up by hand. Not even if we had 5 extra people focused on that (unless they were paid, soulless, human bots, then maybe). Extra devs could be useful for PRs or tools, but 1200 issues is a job for data mining algorithm, not a person.

If we lose 50 useful issues in the process it's still not a big deal - the remaining 50 useful issues will together get a much higher chance of actually being reviewed than the combined chances of all useful issues otherwise.

The bot for that wouldn't be all that hard. I once wrote a bot that automatically parsed all PRs assigned to me to help me with mass merges. I can't use it now because jq hates Windows at the moment, but I still have it around. Modifying it (or rewriting from scratch) to close issues wouldn't be that hard.

[illi-kun]

General idea seems to be useful, but I'd prefer to start with increased period of time (how about 6 months?), "suggestion" and "enhancement" stuff with no assigns. Actually, it's not so difficult to shoot it down manually, the biggest part of time I've spent for closing them is to review the content and decide if it worth for saving.

[mugling]

We've been using the same issue close template I wrote a while ago. If we go with automated closure could probably use that also.

A bot could select a list of the most likely candidates for closure so we could reduce the effort of manual review but when all is said and done I wouldn't object to automated closure if nobody wanted to undertake that task.

[Coolthulhu]

General idea seems to be useful, but I'd prefer to start with increased period of time (how about 6 months?), "suggestion" and "enhancement" stuff with no assigns.

Sure, that 3 months was just an example.
I'd filter issues not by "suggestion or enhancement", but "lack of tags that aren't suggestion or enhancement".

[codemime]

They should probably be marked with something like "auto closed" label
to easily dig them up if needed and distinguish from the others.

that lack a bounty or "Bug" label.

also, Crash and Milestone ones.

No one is going to review those old ideas to find something to implement.

I occasionally search for useful information in old issues.

[mugling]

Whilst we are working through issues please can we tag those that are necessary in the next release as 0.D. I'm starting to work on a plan for release engineering to get a stable release out this year

[stormsson]

Is there a "starting guide" for developers?
i don't mean a guide on how to write code, but something about the code structure, the logic behind it, and some document that can allow an already proficient developer to join the party.

A project design document, while maybe will not help with the open issue problem, could help on the "developer quantity" problem :D

[mugling]

@stormsson no, but that's a reasonable suggestion. I want to look at the development model and try and make it more efficient for developers to collaborate on issues. One option is pair programming which can often be a good way to bring a new developer up to speed on some critical areas of the code base.

[hmstanley]

yea, was gonna ask the same thing. as @stormsson. I can write lua and edit .json pretty easily, but don't want to start mucking up stuff I have NO context with (i mean I do that with my own copy of CDDA), but it would be nice to help out, I actually love this game and would be honored to help

[stormsson]

@mugling i can help with that, i write that kind of docs for living :D

Another possible solution to ease the joining of users is to create a virtual machine with the project dependencies already configured: yesterday i tried to build the source with the info provided in the how to compile doc, but haven't been able, so i guess other may have the same problems to join

[illi-kun]

Re: suggestions/enhancement:
I've closed some of old issues previously in delicate manner, and sorted out only minor issues or request of pure expansion. Since all active devs agree that list of active issues should be decreased, I'm closing more old suggestions manually.

But we have other issues we're not able to deal with automatically:

• assign labels to issues (Currently, we have ~90 issues without tags. I'm working on it, but if you see inappropriate labels assigned feel free to fix it).
• check if old bug reports are still actual. I don't want to close old bug reports just because the are old, it's weird to do that in the _bug tracker_, but it will be great if someone is able to test them and confirm the are actual (extra points for save files for easier checking that).

Also, I have a question: are current labels description enough for persons who actively used them? Do we need any other labels, like 'mapgen' or any others?

[stormsson]

i was curious the virtual machine environment would work.

I actually made the virtual machine and the build process succeded, at least for the linux x64 build with tiles.

If someone with better skills than mine would like to double check if is viable, this could be a resource to skip the configuration process , and allow a new dev to jump on the project from the start in a few minutes.

The instructions would be something like
1) download virtualbox
2) download the vm
3) run the vm

[Coolthulhu]

Do we need any other labels, like 'mapgen' or any others?

Mapgen, z-levels, bionics/mutations (can be one), AI (or monster), tiles
Perhaps also "organization" for things not related to the game code and content - like this PR.

[illi-kun]

Okay, Organization, Mapgen, Z-levels were created. Bionics is a label I created about a week ago.

[mugling]

Issue clearance (nearing <1000) is temporarily painful due to number of notifications but ultimately necessary for the projects long-term survival.

[illi-kun]

Label Vehicle was introduced.

[illi-kun]

@Coolthulhu @mugling since you are most active devs I'd prefer do not touch your open issues. Please review list of issues published by you and close the issues you don't need anymore if you have time for this or give me some general hints about politics I need to apply to your issues.

Currently, number of open issues < 1000, number of issues without labels < 15, and I estimate it as progress. The next step is to double check some old bug report to validity (and @Oskar636 already started this activity).

Any other ideas about reduction of number of issues? Do I need to close suggestions even more aggressively (with behavior "close everything old which is suggestion / enhancement without validated tag and active assignment)?

[Oskar636]

@illi-kun Yaaay we passed the 1000 mark :D ! I'm glad to help in any way I can. For anyone interested in further help, you can search for open issues by commenter:Oskar636 and label:bug and look for these that need confirmation so we can close a few pending to get confirmed, or confirm that I'm just dumb at reproducing bugs.

[Coolthulhu]

I'd say that every old (6+ months) feature request which doesn't have an assignment should be closed. Those are unlikely to be reviewed.

Basically, the only kind of old issue that should stay should be bug reports, valid balance complaints and valid UI complaints.

[mugling]

I'd agree with @Coolthulhu - a bloated bug tracker is unusable. We should focus on tagging new bugs as they arrive, possibly assigning them to a developer and/or milestone

[kevingranade]

A milestone shouldn't be necessary, but requiring a feature request to have
a developer (self) assigned would be a nice way to filter out suggestions
that no one thinks is a good idea, but no one wants to close outright.

I do have to point out that this carries a real risk of certain issues
recurring over and over instead of being perpetually open.

[mugling]

A milestone shouldn't be necessary, but requiring a feature request to have a developer (self) assigned would be a nice way to filter out suggestions that no one thinks is a good idea, but no one wants to close outright.

I do like this idea and wouldn't object to also assigning other developers as it's trivial to change an assignment. How does everyone else feel about it?

[illi-kun]

For the record: Label Vitamins was introduced for easier handling and review of vitamins related topics.

[illi-kun]

With November's progress (876 closed issues, yay!), we have good dynamics:

[codemime]

Do we need any other labels, like 'mapgen' or any others?

I think Crafting label would be also useful.

[Asmageddon]

What about a minor/insignificant tag?

[kevingranade]

On Jan 4, 2017 1:27 AM, "Asmageddon" [e-mail] wrote:

What about a minor/insignificant tag?

I very much like this idea, the last thing I want to do is lose valid bug
reports because they're too minor, triage by severity is much better.

[Coolthulhu]

I'd rather see it as minor by default, some other tag (validated? moderate or important?) once it isn't minor. With flags like "bug" or "crash" implying non-minor.
Only closing explicitly minor issues defeats the point or mass closing minor issues.

[Asmageddon]

You could, alternatively, have some group of contributors out there tagging issues, to ease the strain on the core devs.

[kevingranade]

Only closing explicitly minor issues defeats the point or mass closing minor issues.

We shouldn't be mass closing issues at all, just tag them (or treat untagged issues as minor/need triage) and filter them out if you don't want to look at minor issues.

[codemime]

Added new labels: Tiles and Crafting.

[Asmageddon]

By the way, I wanna get into contributing to C:DDA more, but don't have a compiler set up, so if you label more stuff that can be fixed/improved/implemented with JSON changes, I can get on these.

[rm-code]

I think we should make better use of the labeling system github provides and as @kevingranade suggested use it to mark any incoming issues. The only problem I see with it is that somebody would have to actively maintain the tracker and make sure that issues are labeled correctly.

Currently the labeling is pretty inconsistent and therefore I'd like to suggest a different slightly more verbose appraoch. I'm using a pretty structured labeling approach for my own projects. It certainly isn't perfect but hopefully it provides some food for thought.

As you can see my labels are divided into categories by using the prefixes: "Priority", "Status" and "Type". The benefit of using a prefix like this is that the labels are always displayed in the same order in the repo and therefore make it easier to visually grep. But even more importantly it makes it a lot easier to apply certain filters. Because you know all issues have a priority, a certain status and a certain type.

I would suggest these labels:

Priority indicators

• Priority: Critical (This should only be applied to blocking issues for the next version such as crashes)
• Priority: High (Important features and fixes, but non-blocking)
• Priority: Medium
• Priority: Low

Status labels

• Status: Accepted (Confirmed bug, feature)
• Status: On Hold
• Status: Needs Reproduction (see below)
• Status: Duplicate
• Status: Invalid (The counterpart to accepted)

Type labels

• Type: Bug (Crashes wouldn't get a special label)
• Type: Question
• Type: Feature
• Type: Code Maintenance (such as #20819)
• Type: Organization (such as this issue)
• Type: Bounty (currently we have "bounty" and "bounty issue" - is there a difference?)

Mod labels (could be handled as misc)

• Mod: Gunmod
• ...

Misc labels

• X: Vehicles
• X: Z-Levels
• X: macOS / OSX
• ...

I know this seems like a lot of work, but it pays off in the end. Especially when working with milestones.

Auto-closing

Last but not least it would help us with auto-closing issues. As discussed earlier it might be counterproductive to close old issues by default.

But for example look at this bug report I created: https://github.com/CleverRaven/Cataclysm-DDA/issues/20316

It is hard to reproduce (maybe even a once-in-a-lifetime) type of bug. Several people have tried to reproduce / fix it. An issue like this would be labeled as:

• Priority: Low (it didn't have game breaking consequences)
• Status: Needs Reproduction
• Status: bug
• X: Vehicles

After a month or so no updates have been received towards fixing this issue nor was anybody able to reproduce it. So the issue is closed and the label is changed from

• Status: Needs Reproduction

to

• Status: Invalid

Because IMO chances of fixing a bug that isn't reproducible in any way are slim to none... especially if it is of low priority.

I know this might seem overly complicated, but looking at how many labels we currently have and how sporadically they are used I think this would be a step in the right direction.

[rm-code]

The other thing I thought about was banning feature requests from this repository's issue tracker.

Instead we could open a new repository in:
https://github.com/CleverRaven/Cataclysm-DDA-features-requests/

Which would only be used for tracking feature-requests. But obviously I don't have any information about the amount of feature requests this repository receives and wether this would be a viable option.

Personally I don't think that feature requests need to be tracked in the issue tracker of a project of this size.

Anyway ... as I said this is just food for thought.

[Asmageddon]

I don't really feel like that would have much improvement over tagging and categorization, I mean, the github issue tracker isn't really that bad.

Plus a lot of feature requests touch upon (perceived?) issues, and having a separate tracker for them just feels awkward, really.

[rm-code]

Yeah, as I said that's just another idea. The type: feature tag should work for that too.

[kevingranade]

Some action taken, number of open issues is reducing, and we're continuing to work on it.

Ironically, this issue has now joined the horde of noise-causing issues that it was intended to address, as such I'm closing it.