RFC: Introducing an LLVM Community Code of Conduct

Your report will still be kept confidential exactly as above, but also
feel free to (anonymously if needed) email conduct at llvm.org if needed.

I have slight reservations towards this. A general conduct email is good,
but there are cases where you would like to contact individuals.

This is for example, when the report goes against a member of the conduct
team itself or the LLVM core team - for the reporter, it is intransparent
whether that person is included in (contact at llvm.org) or if they are openly,
might resort from reporting.

This is not a constructed thing, I had such cases.

I can also recommend the approach taken by cfgmgmtcamp.eu, which provides
contacts to people outside of the organisation in case of issues.

http://cfgmgmtcamp.eu/code_of_conduct.html

Best,
Florian

Your report will still be kept confidential exactly as above, but also
feel free to (anonymously if needed) email conduct at llvm.org if needed.

I have slight reservations towards this. A general conduct email is good,
but there are cases where you would like to contact individuals.

This is for example, when the report goes against a member of the conduct
team itself or the LLVM core team - for the reporter, it is intransparent
whether that person is included in (contact at llvm.org) or if they are openly,
might resort from reporting.

I expect the members of the committee monitoring the list to be public. I would not expect others to have any access to the reports – that is the specific intent of these remaining confidential.

We could add more direct contact instructions as the actual advisory committee takes shape. We will also have additional contact information specific to any major event (like the developer’s meeting) where staff can be involved and help facilitate. I’m also (of course) open to other specific suggestions about how to better facilitate people reporting issues.

This is not a constructed thing, I had such cases.

I absolutely believe that.

I can also recommend the approach taken by cfgmgmtcamp.eu, which provides
contacts to people outside of the organisation in case of issues.

It’s not clear these are strictly outside the organization, but certainly outside the specific staff of the event. We can and should ensure that there are clear non-overlapping members of these different groups (staff at events, advisory committee members, etc.) which should aid in ensuring people can find someone to report issues to.

I would not expect others to have any access to the reports -- that is the specific intent of these remaining confidential.

I didn't want to imply anything else.

We could add more direct contact instructions as the actual advisory committee takes shape. We will also have additional contact information specific to any major event (like the developer's meeting) where staff can be involved and help facilitate. I'm also (of course) open to other specific suggestions about how to better facilitate people reporting issues.

I think additional individual contact information of the (some) members should suffice. But the option should be mentioned in the Code of Conduct because it is the first point of reference.

It's not clear these are strictly outside the organization, but certainly outside the specific staff of the event. We can and should ensure that there are clear non-overlapping members of these different groups (staff at events, advisory committee members, etc.) which should aid in ensuring people can find someone to report issues to.

Sure, any group that has no direct involvement with the event/project at hand should suffice.

Best,
Florian