I think Jakarta EE and MP have more important things to do than duplicate something that is already there for all projects.
For example MP adopting the EFSP and getting whatever WG for that would be a better way to advance things.
The Eclipse Foundation has a Community Code of Conduct [1] that one
would assum also covers Jakarta. But given recent discussions, I
(speaking just as a community member) would propose that it would be
greatly beneficial to the Jakarta community and brand if Jakarta
itself were to specifically adopt an official code of conduct (the
Eclipse one or a more specific one) which governs the experts as well
as the community.
I would suggest that the following areas be covered by such a code:
* Behavior (being respectful, accepting responsibility, honesty,
empathy, safety)
* Content (clarifying objective vs subjective language, being concise
and rigorous, avoiding hyperbole and "argument strategies")
* Remedy (what to do in case of violations, how to correct problems,
how to deal with mistakes)
The behavior area I consider to be what a traditional "project" code
of conduct (such as Contributor Covenant, the existing Eclipse Code of
Conduct or similar) would normally cover. This would cover
unacceptable behavior such as abuse, harassment, trolling, personal
attacks, etc.
Jakarta strives to generate specifications. This is more involved,
difficult, and complex than many "normal" open source projects that
one might find on Eclipse or elsewhere. Because of the special needs
of specifications - particularly, the role of clear, concise, and
rigorously correct language in a coherent specification - I would
propose that clear content and communication is also an area of
conduct that should be covered. Just as we must all work a bit harder
to respect one another, we must also work a bit harder to be precise
in our language, in order to provide the best specifications possible.
Imprecise language goes over the line into misconduct when opinions
are asserted as though they were facts, hyperbolic or bombastic
statements are made to maximize emotional impact, or broad
generalizations or other logically fallacious statements are used
deliberately to derail constructive discussion. When developing a
specification - which is by nature required to be as objective as
possible - these kinds of machinations can disrupt or undermine what
may already be a very difficult endeavor.
Finally, a remedial path is necessary because, as humans, all of us
have (and will) make mistakes. The code should outline a path not
only for the spec committee and other official structures to cope with
problems, but also for those community members who have in fact found
themselves in violation of the code, so that they understand how to
make amends and avoid lingering resentment, which can have a
detrimental long term effect on the community. Many such strategies
can be found in typical autism behavior programs, but are (in my
opinion) actually quite useful for any person who finds themselves on
the wrong side of a behavioral problem and are unsure what to do. In
particular, there seems to be credible evidence that "zero tolerance"
policies neither deter nor repair undesirable behavior.
Having a comprehensive code of conduct which is consistently applied
is, in my opinion, a necessary feature of a serious specification body
in this decade. I believe that the lack of a CoC covering these areas
is a deterrent to participation. I know that it is a deterrent to me,
at any rate.
[1] https://www.eclipse.org/org/documents/Community_Code_of_Conduct.php
--
- DML
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
