qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] docs: Add a QEMU Code of Conduct and Conflict Resolution Pol


From: Andreas Färber
Subject: Re: [PATCH] docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document
Date: Tue, 13 Apr 2021 12:23:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

Hi Paolo,

On 13.04.21 09:42, Paolo Bonzini wrote:
> On 07/04/21 17:42, Kevin Wolf wrote:
>>> +* Publishing other's private information, such as physical or
>>> electronic
>>> +addresses, without explicit permission
>>
>> Yes, it's pretty clear that I'm not publishing new information about
>> people when I'm keeping them in Cc: when replying to a thread, or even
>> when they posted in another thread on the list recently. It becomes much
>> less clear for adding people who aren't usually part of the QEMU
>> community.
> 
> If you took the email from, say, the Libvirt or kernel mailing lists,
> that would not be considered private.  If somebody has two email
> addresses and you deliberately Cc him on an address that he's only using
> for communications within his family, that would be a problem.

I have to admit I had originally stumbled over this bullet point myself,
reading it as private=personal. So maybe it might help avoid ambiguities
for non-native readers to formulate it as "non-public" instead?

Like, if someone posts to a public mailing list with their private as
opposed to business address in the footer. Then I would consider it
public. I did intentionally use a private email for topics such as PReP.

Or consider the case you get a bug report not copied to the public
mailing lists from someone you don't know. Then I would still expect to
be allowed to attribute a commit via Reported-by/CC to that person, as
it seems in his/her interest to get the bug fixed and be notified,
unless explicitly requested otherwise.

Mistakes can always happen, but I feel it needs to be the responsibility
of the sender, not of the receiver, to ensure that only data is shared
that the project members may use for valid development purposes.

Not sure how to extend that bullet point to make its purpose/scope clearer.

Cheers,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]