Add caution field about @username to CoC reporting

py0xc3 commented

2026-07-06 17:26:49 +00:00

First-time contributor

Users considering a CoC report should be made aware to not mention usernames with an @ in the beginning in order to avoid these usernames to be informed of the ticket and the ticket's content by pagure.

If users do not know this in advance, this can cause serious confusions and inform, e.g., those people the report is about (who should not read the content, at least not at this stage). At the worst, such a report can cause the escalations the CoC report is actually intended to prevent. It might also damage trust in the processes that promise confidentiality.

This PR will only create a "caution" field as defined by asciiDoc. An example can be seen, e.g., here: https://docs.fedoraproject.org/en-US/beginners-guide/daily_driver/ (search for the sentence "Formatting a drive will erase all data on it", which is in a "caution" field)

Feel free to adjust the wording etc. There is definitely space for improvement :)

Users considering a CoC report should be made aware to not mention usernames with an @ in the beginning in order to avoid these usernames to be informed of the ticket and the ticket's content by pagure. If users do not know this in advance, this can cause serious confusions and inform, e.g., those people the report is about (who should not read the content, at least not at this stage). At the worst, such a report can cause the escalations the CoC report is actually intended to prevent. It might also damage trust in the processes that promise confidentiality. This PR will only create a "caution" field as defined by asciiDoc. An example can be seen, e.g., here: https://docs.fedoraproject.org/en-US/beginners-guide/daily_driver/ (search for the sentence "Formatting a drive will erase all data on it", which is in a "caution" field) Feel free to adjust the wording etc. There is definitely space for improvement :)

py0xc3 added 1 commit

2026-07-06 17:26:50 +00:00

Add caution field about @username to CoC reporting b2bb540e33

Users considering a CoC report should be made aware to not mention usernames with an @ in the beginning in order to avoid these usernames to be informed of the ticket and its content by pagure

jflory7 added the

labels

2026-07-08 18:58:42 +00:00

jflory7 self-assigned this

2026-07-08 18:58:45 +00:00

jflory7 commented

2026-07-09 04:10:39 +00:00

Owner

Hi @py0xc3, I recently addressed this in pagure.io/CoC@61df2a10f10c58fd63e95bc2a687a94f14f3b9ad and I also edited the Code of Conduct issue template. While this is an issue we take seriously, I don't think it is right to document this in the official Fedora Code of Conduct policy document. Changing the policy document would require wider review; this is why we have the clarifications document.

That said, I am not sure I am too keen about putting this into published documentation on docs.fp.o right now.

Hi @py0xc3, I recently addressed this in [pagure.io/CoC@61df2a10f10c58fd63e95bc2a687a94f14f3b9ad](https://pagure.io/CoC/c/61df2a10f10c58fd63e95bc2a687a94f14f3b9ad?branch=main) and I also edited the Code of Conduct issue template. While this is an issue we take seriously, I don't think it is right to document this in the official Fedora Code of Conduct policy document. Changing the policy document would require wider review; this is why we have the clarifications document. That said, I am not sure I am too keen about putting this into published documentation on docs.fp.o right now.

py0xc3 commented

2026-07-09 08:09:45 +00:00

Author

First-time contributor

Ah, yeah. Makes sense. It seems the ticket of this commit is private, so I didn't see it. Just saw the official Docs and the pagure behavior.

Yeah, with your commit it might be already mitigated as well. I would have preferred as much transparency as possible in such cases, but I know that this sometimes leads to ****storms that do not add anything constructive but only fights not considering all context. So I understand your point.

I close this then as fixed by CoC@61df2a10f10c58fd63e95bc2a687a94f14f3b9ad.

I assume it is already on your To Do list, but keep in mind that Forge has the same behavior (in the end, it's still a software development tool). Unless someone works on having private tickets to behave different, the warning should be kept after the migration.

Thanks or taking care & the feedback :)

Ah, yeah. Makes sense. It seems the ticket of this commit is private, so I didn't see it. Just saw the official Docs and the pagure behavior. Yeah, with your commit it might be already mitigated as well. I would have preferred as much transparency as possible in such cases, but I know that this sometimes leads to ****storms that do not add anything constructive but only fights not considering all context. So I understand your point. I close this then as fixed by CoC@61df2a10f10c58fd63e95bc2a687a94f14f3b9ad. I assume it is already on your To Do list, but keep in mind that Forge has the same behavior (in the end, it's still a software development tool). Unless someone works on having private tickets to behave different, the warning should be kept after the migration. Thanks or taking care & the feedback :)

py0xc3 closed this pull request

2026-07-09 08:09:45 +00:00

misc commented

2026-07-09 10:46:49 +00:00

Contributor

Funny how the same problem keep coming back: https://pagure.io/pagure/issue/4978

In the end, that's a structural problem on the forge, we can't optimise the tool for collaboration (eg, easily add people on a tikcet) and for confidentiality (eg, not easily add people to a ticket)

Funny how the same problem keep coming back: https://pagure.io/pagure/issue/4978 In the end, that's a structural problem on the forge, we can't optimise the tool for collaboration (eg, easily add people on a tikcet) and for confidentiality (eg, not easily add people to a ticket)

py0xc3 commented

2026-07-09 11:02:59 +00:00

Author

First-time contributor

In the end, that's a structural problem on the forge, we can't optimise the tool for collaboration (eg, easily add people on a tikcet) and for confidentiality (eg, not easily add people to a ticket)

Personally, I think it would be useful on the long term to move CoC tickets out of any git forge, as these tools ain't intended for that.

But we might shift this discussion to somewhere else, this is closed :) But if someone has related experience, it might be useful to open a Council or CoC ticket with a suggestion for a tool that is appropriate for something like that. Then it can be discussed and evaluated.

The only thing I have in mind is a team workflow in Discourse, but many don't like to be forced to Discourse, and the privacy there is also always limited. So others might have better ideas to open a ticket about it :)

> In the end, that's a structural problem on the forge, we can't optimise the tool for collaboration (eg, easily add people on a tikcet) and for confidentiality (eg, not easily add people to a ticket) Personally, I think it would be useful on the long term to move CoC tickets out of any git forge, as these tools ain't intended for that. But we might shift this discussion to somewhere else, this is closed :) But if someone has related experience, it might be useful to open a Council or CoC ticket with a suggestion for a tool that is appropriate for something like that. Then it can be discussed and evaluated. The only thing I have in mind is a team workflow in Discourse, but many don't like to be forced to Discourse, and the privacy there is also always limited. So others might have better ideas to open a ticket about it :)

jflory7 commented

2026-07-10 18:13:37 +00:00

Owner

@py0xc3 I have been following the upstream private issues work on Forgejo, and from what I am seeing, the development of this feature will be sufficient for our needs and protect the level of security required for this data. That said, I heard some folks, maybe @gwmngilfen, might be toying out a possible workflow on Discourse after all. Not sure what it will look like yet.

❤️ 1

py0xc3 commented

2026-07-10 20:10:35 +00:00

Author

First-time contributor

Sounds good :)

Pull request closed

Please reopen this pull request to perform a merge.

Rows
Columns

Add caution field about @username to CoC reporting #293

Pull request closed