4 ms·

Well... As a maintainer of multiple repos: a) If you don't trust the maintainer, the project is already dead. b) If the maintainer is power hungry, you're alr

Well... As a maintainer of multiple repos: 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.

Avamander 8y ago
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.
craftyguy 8y ago
> 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.
- toomuchtodo 8y ago
  > 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.
  - craftyguy 8y ago
    > 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.
    - deleted 8y ago
      [deleted]
rurban 8y ago
Unfortunately not. 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.

Avamander 8y ago

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.

craftyguy 8y ago

> 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.

toomuchtodo 8y ago
> 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.
- craftyguy 8y ago
  > 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.
  - deleted 8y ago
    [deleted]

rurban 8y ago

Unfortunately not. 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.