I see a lot of potential for abuse. Maintainers should not have the power to make everything they don't like disappear. Neither do I see what this feature tries to solve that say filtering out closed issues with `invalid` tag doesn't.
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.
a) The project might be used by other people - say a public disclosure of a vulnerability after no reaction
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.
> a) If you don't trust the maintainer, the project is already dead.
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.
> 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.
> The platform is not built for you as a free consumer to audit projects and ensure compliance with your own criteria.
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.
I'd like to comment here that issue trackers are tools for maintainers, not for users. A maintainer doesn't owe you any response to issues, nor do they owe you any way to report them. The maintainer has the right to stop working on their code at any point and completely take it off GitHub at their own discretion, should they want to.
(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.
Most bugtrackers don't allow outright deletion of tickets. They allow closing them as invalid/irrelevant/offtopic or whatever tagging metadata that particular system allows, but they don't allow for deletion. There's a permanent public record and audit trail.
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.
> Maintainers should not have the power to make everything they don't like disappear.
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?
I hope you can see the list of deleted issue #'s, not the content, but just enough to get a feel for if there is an unnecessarily large amount of issue deletion going on.
This seems good. I once saw a very cringey question asked on a transgender developer’s Ask me Anything (AMA) repo that was totally inappropriate harassment. It made me feel bad that they couldn’t delete the issue.
I can see use cases for a delete function, but as people mention it’s all about how you manage abuse.
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.
22 comments
[ 4.2 ms ] story [ 63.5 ms ] threada) 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.
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.
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.
My first thought: security disclosures.
(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.
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 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...
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.