GitHub: You've been asking for it. You know the issue(s). Delete 'em
twitter.com
twitter.com
(If you think that issue trackers should be for users to be able to tell each other if they've experienced the issue too, then that's part of the problem with "+1", "Me too", "fix this please", and other useless comments. That's what a forum is for, and today they're super-easy to create. You don't even have to host them yourself, nor do you need to be affiliated with the project!)
Lesson: if you don't trust the maintainers, you can't trust the software. Keep your own fork and issue tracker if this is a problem, but don't force maintainers, many of whom are not acting in a professional product management capacity, to do extra work for your benefit.
I feel that most of your comments are misdirected here. GitHub issues already allowed "+1" and other markers on the issue or its comments. That's not really germane to deleting an issue completely.
And regarding trackers being for maintainers, that's not strictly correct. They are for end use by maintainers durig the course of their work, but they are in many projects the interface between users and developers for officially reporting problems, including outright bugs to usability concerns and feature requests. Part of the unwritten contract here is that users will use the system for its intended purpose. But the other side is that developers will take that feedback seriously and use it appropriately. Censoring by deletion is a rather dramatic change, and not one I'm sure is for the best. There have been many instances where unprofessional behaviour has been visible because of the public audit trail, as well as where controversial issues have been openly discussed. Allowing any dissenting opinions to be silenced is not necessarily for the greater good.
a) If you don't trust the maintainer, the project is already dead.
b) If the maintainer is power hungry, you're already screwed.
Sometimes, we seek for programmatic solutions where trust should be employed. If you can't trust the maintainer, just forget about the project, regardless of whether maintainer can delete issues or not. I mean, we can already force push to delete history, for example.
I feel like this argument doesn't really address the problem that non-delete-able issues helps to address. You may trust a maintainer right up until they do something that causes you to distrust them. This takes away your ability to continuously audit the maintainer and takes away data points which may cause you to suddenly distrust them.
The platform is not built for you as a free consumer to audit projects and ensure compliance with your own criteria. You would need to build you own tooling for that, and one might argue that is out of scope for Github to build. moosingin3space addresses this well further upthread.
Meh. Of course it is not built for that, however it did provide a public record of sorts that could be used for that purpose. I don't think gitwhatever should be in the business of helping folks audit projects for personal criteria compliance, but I do see this change as having a negative impact on users' ability to collect information about developers/maintainers to make that decision.
The use case for issue deletion are security issues, which should at least be hidden from public for some time. deletion would work as simple ad-hoc feature until hiding issues (visible only to creator and admin) can be implemented. it's ruby so I guess it would take 6 months for such feature.
b) The deletion action is much much more extreme than what a maintainer could do before. Anything controversial is still quite public vs. now it can be just deleted without a trace.
Why not? It's their project, it's their time they are spending working on their project. Why should a random user who contributed nothing to a project have power over those who created the software and donate their time and expertise to the benefit of others?
My first thought: security disclosures.
If a project owner really wanted they could just delete the whole repo (which includes issues et all) with no warning or confirmation from collaborators. But that’s a larger more destructive move, whereas, deleting a politically fuelled issue can be abused with far less repercussion.
Not on an issue, but I did once have a moment where I could have used a delete function on a pull request. I merged a pull request with my personal account on a repository I had only been working on under a pseudonym. From memory even resetting to an earlier commit and re-merging again with the correct identity didn’t work as GitHub kept a record of the original merge on that pull request. Which only further tied my two identities together as I tried to correct the mistake.
My uninformed guess is that enterprise users asked for this feature for their own repos and it was eventually cargo-culted into the OSS side.
More reason to use Gitlab, I suppose.
It seems like you can actually delete issues on GL, but only project owners: https://docs.gitlab.com/ee/user/project/issues/deleting_issu...