The usual concern with this particular source of the document - can a document from another source be used?

can a document from another source be used?

If you mean "can this document here be used", then yes it should be OK because it is licensed as CC BY (although perhaps a link to the license could be added in the text, as required by CC BY).

If you mean "can this document here be used", then yes it should be OK because it is licensed as CC BY (although perhaps a link to the license could be added in the text, as required by CC BY).

No, that's not what I mean. I mean "Can a CoC of different authorship be used?"

Can a CoC of different authorship be used?

It really depends what the content is of another CoC. The one here is mostly "common sense" but the idea is to make it explicit. If there is another CoC that has the same intent then it could be considered.

So, overall concerns with (various) Code of Conducts are:

1. History and background of a particular instance.
2. Overbroad requirements.
3. Stipulation that too many things are left to (dynamic) consideration of those in powers to enforce CoC.

The examples of CoC alternatives:

1. Python Software Foundation CoC: https://www.python.org/psf/codeofconduct/ . It's almost unbelievable by the current "standards", and almost fully devoid of authoritarian/totalitarian/punitive language.
2. Django CoC: https://www.djangoproject.com/conduct/ . This is actually more detailed than contributor-covenant. But has overbroad stipulations:

In addition, violations of this code outside these spaces may affect a person's ability to participate within them.

I realise I haven't contributed enough to this project (not even remotely) to have a say but because I feel quite strongly about this issue I decided to comment.

Many open source projects now include one

I wouldn't jump on that particular bandwagon. IMO it is a kind of virtue signalling that comes with unexpected strings attached, but if having a CoC became a fashionable necessity why not something like this? https://github.com/domgetter/NCoC 😉

Thanks both for the feedback, it is appreciated. It would be good to iterate on the text to get some kind of consensus on this issue, but I doubt there will ever be unanimous agreement.

Overbroad requirements.
Stipulation that too many things are left to (dynamic) consideration of those in powers to enforce CoC.

I think these points are more acute without a CoC, because the "requirements" are then hidden/implicit, and "those in power" would always have the ability to enforce something/anything.

Python Software Foundation CoC

I did consider this, but it was quite specific to Python (referencing PEPS for example). But it could be adapted to the purposes here.

I wouldn't jump on that particular bandwagon. IMO it is a kind of virtue signalling that comes with unexpected strings attached

I tend to agree, I wouldn't like to just do something to follow the crowd. Also I prefer simpler things, eg saying less rather than more, just like the MIT license is nice and simple (no strings attached).

But, having a popular open source project comes with responsibility to have some structure around how it operates, and a CoC is part of fulfilling that responsibility.

I agree wholeheartedly with the sentiment, but worry about the practicalities. After all, that exemplary Python CoC did nothing to prevent the recent PEP572 débâcle.

Somehow we have to find a way to ensure that discussion remains respectful, considerate and constructive and create an environment which encourages those who may be less assertive to stick around.

Alas we still have threads like this where a constructive discussion became bogged down with accusations and veiled personal slights.

a way to ensure that discussion remains respectful

Looking around at other both online and real-life places where there's a good vibe, so to speak, the main way to make this happen as far as I can tell is always the same: the people being the most active always act exemplary and the rest just follows. Or don't, but then they get ignored or dealt with in the same manner, after which they either give up and disappear, or slowly start to act normal. So, peer pressure basically, but used in a good way.

Whether a document can enforce that is something else. I don't think it can, though it might help a bit.

After all, that exemplary Python CoC did nothing to prevent the recent PEP572 débâcle.

It's baffling that there're individuals that think that code of conducts are there to prevent some kind of "debacles". Let me explain what kind of behavior they are there to prevent. So, when I rented a bicycle in San Francisco, somewhere on the way to Golden Gate Bridge I passed by homeless person/junkie/alcoholic which made a punch gesture in my direction (in quite close up). Well, I don't care, but someone could crash from the bicycle in surprise. That's the kind of behavior and audience CoCs are there to protect from. And example of San Francisco is not accidental of course - it's known to be a capital of "political correctness went far, far". And that's the contrast with what happens there on the streets. And of course, CoCs have intention to protect infiltration of that behavior from the streets into project spaces. But in reality what they often achieve is building walled gardens with artificial reality, only widening the gap with the actual reality. And that's per the best intentions, subconsciously many ardent proponents of CoCs build little north koreas.

Alas we still have threads like this where a constructive discussion became bogged down with accusations and veiled personal slights.

So, statements like this is violation of the CoC proposed here on the following accounts:

• Being respectful of differing viewpoints and experiences
• Gracefully accepting constructive criticism
• Showing empathy towards other community members

Moreover, the whole statement seems to be retaliation for you being found violating open-source licensing.

Python Software Foundation CoC

I did consider this, but it was quite specific to Python (referencing PEPS for example). But it could be adapted to the purposes here.

So, unlike for example licenses, which are well established and formal notion, where changes are generally discouraged as lead to non-clarity, the latest surge of CoCs application to people-from-streets, considered good-intentionally, can't treat CoCs anything like that. So, any CoC is expected to be adapted for a particular community. In particular contributor-covenant itself is just a template with blanks to fill. E.g. blank phrase:

Representation of a project may be
further defined and clarified by project maintainers.

Should be replaced with actual definitions and clarifications.

I think these points are more acute without a CoC, because the "requirements" are then hidden/implicit, and "those in power" would always have the ability to enforce something/anything.

Well, that's both very naive/simplistic and both cunning point of view.

So, first of all, human society exists for quite a long and worked out mechanisms to deal with that stuff, the need for punitive/repressive institutes. That largely involves having a single full-power institute for entire society, and largely independent from other branches of endeavor of the society. Obviously, there're always a lot of group-specific rules in the society - but they are just those, subsidiary to the main law.

Secondly, it's absolutely true that those in (local) power always have the ability to enforce something/anything. And that would get response from wider community/society. And it's usually only if someone seeks to establish authoritarian power, they establish explicit rules and laws citing their power to enforce anything of their whim.

Moreover, the whole statement seems to be retaliation for you being found violating open-source licensing.

I'm not "retaliating" for anything. I have no desire to engage in conflict and my habit is simply to withdraw from such situations. My aim is to suggest we adopt less confrontational ways of dealing with problems.

The text, and your similar comments in the forum, are there for all to read. In my opinion you handled a simple oversight in a needlessly aggressive fashion; a polite PM would have received my immediate attention and a sincere apology. Public accusations forced me to make public responses: the exchanges were unfortunate and entirely unnecessary.

I remain utterly baffled by your subsequent "admittedly subjective" criticism; I honestly don't know what to make of it. When we make errors of fact, we have mechanisms for fixing them (issues, PR's). We all make mistakes. Most of us (self included) welcome having them pointed out or rectified.

"Subjective" issues are more tricky. If you disagree with my approach it would help if you could elucidate the issues clearly. I would then have a chance to think about them and to consider adapting. I would advocate a PM for this as I think in a public forum such discussion adds to the noise and increases the risk of the discussion turning overly personal.

Further, for outsiders considering MicroPython, glancing through GitHub provides useful insight into the nature of the community. I believe people have been discouraged by what they have seen in the past. Some things are best handled in private.

These are just my personal views on how we might conduct ourselves better.

@peterhinch: Sorry to interrupt you, but this issue is dedicated to discussion of a CoC document. From my PoV, the "licensing" matter was resolved. If you still have any questions, like why someone, as a response to your public actions, after patiently waiting and giving you benefit of doubt for almost a year, finally brought the matter up likewise publicly, don't hesitate to ask in the original issue.

+1 for peer pressure and leading by example as robust community building mechanisms.

Even though this PR is not merged there is still an expectation that people are civil. Recently pfalcon was hostile in comments and detrimental to the community here, so he was blocked from the GitHub MicroPython organisation.

Tough decision; on one hand it's a pity it has come to this, on the other hand it should be beneficial for the community. I for one won't miss having to extract the gist from the snarkiness in comments.

@dpgeorge Even if I can understand you action, I think it is too harsh. Paul is an excellent expert and has contributed a lot to the state and public recognition MicroPython is in. And we can expect that is is able to continue his good work, if we let him. Obviously he is very emotional in his discussion, more than"careful" engineers usually are, which I do not like either. But I can stand it and we should be able to stand it. I do not see his posts as aggressive, but just unduly exited. But other people can get exited too, and just may put that into more elegant style.

@robert-hh If this would be up for voting I honestly cannot say right away what I'd do. In the end I'd probably lean to your side, for the reasons you mention. Yes I can stand it, also because I got used to it. But I find it a bit strange that you do not see at least some postst as unjustly attacks. I'm not going to look for examples but some comments certainly do come over far beyond just 'unduly exited', to the point it doesn't simply look like a matter of writing style anymore.

Of what I have seen pfalcon has done good work and is an expert. However, the way he express himself differs from what I would say. But why not embrace him and let us show how to behave...

Recently pfalcon was hostile in comments and detrimental to the community here, so he was blocked from the GitHub MicroPython organisation.

@dpgeorge, decisions like these are your prerogative and so is deciding to listen to feedback or not. For what it's worth, I agree with @robert-hh. I find pfalcon's communication style abrasive at times but I think that's easily outweighted by his contributions to the project.

I'm genuinely impressed by the level of tolerance expressed above, but a bigger issue is at stake.

MicroPython is funded by George Robotics. Potential customers (especially commercial ones) are likely to view these forums to assess the quality of support. Some threads which have occurred over the years would send them running for the hills. In my view Damien is right to ban any person who (after reasonable warning) continues to behave in an unprofessional manner.

Loss of a potential customer is an event which occurs silently: you seldom get the chance to know it's happened. You won't find a 1-star review on Chip Advisor. As a businessman you have to be proactive.

We all have a responsibility to maintain a professional atmosphere in official, public MicroPython forums.

Obviously he is very emotional in his discussion, more than"careful" engineers usually are, which I do not like either. But I can stand it and we should be able to stand it.

I strongly disagree with this last statement: his comments (here and in the forum) can border on harassment and abuse which 1) is definitely not something anyone should be expected to stand; 2) can lead to the impression that such behaviour is tolerated, which it is not. There needs to be some consequence for unwanted behaviour, and, after repeated requests for pfalcon to "be more civil" that don't work (he has had a lot of chances), blocking seems to me to be the only remaining option.

decisions like these are your prerogative and so is deciding to listen to feedback or not

I'm happy to take feedback. Due to the nature of the discussion some people won't provide feedback in the public forum here, in which case feel free to email me personally (see git log for email address).

A revised CoC was merged in e0befd9