back-merge of policy artifacgts

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,185 @@
+# Code of Conduct
+
+## Our purpose
+
+CIMTool is an open-source project maintained under the stewardship of the
+[UCA International Users Group (UCAIug)](https://cimug.ucaiug.org/). Its
+contributors and users include utility engineers, vendor staff, researchers,
+standards participants, and independent practitioners, working across many
+countries, organizations, and native languages.
+
+We want CIMTool to be a project where a contribution is judged on its merits and
+its fit with the project's direction, never on who is offering it, and where anyone
+with something useful to offer can offer it without first having to prove they
+belong.
+
+This document states what we expect of participants, what we will not tolerate,
+and what happens when the line is crossed.
+
+## Scope
+
+This Code of Conduct applies to all project spaces, including the CIMTool
+repositories, issues, pull requests, discussions, commit messages, code review
+comments, and the project's documentation sites. It also applies when an
+individual is representing the project in public, whether at a conference, in a
+CIM Users Group session, on a mailing list, or on social media.
+
+Participation in UCAIug meetings and working groups is additionally governed by
+UCAIug's own policies. Where the two overlap, both apply.
+
+## Expected behavior
+
+Participants in this project are expected to:
+
+- **Assume good faith.** Contributors come from very different engineering
+  cultures. A blunt review comment is more often a language difference than an
+  insult. Read charitably before responding.
+- **Keep disagreement technical.** Criticize the design, the code, or the
+  reasoning. Not the person who produced it. "This breaks single inheritance in
+  the profile model" is a review. "You clearly don't understand CIM" is not.
+- **Accept review gracefully.** Having your work critiqued is the point of
+  review, not a cost of it. Maintainers, likewise, owe contributors reviews that
+  explain rather than merely reject.
+- **Be patient with newcomers.** Everyone writing XSLT builders today was once
+  someone who had never opened one. The project's future depends on that
+  transition continuing to happen.
+- **Respect the time of others.** Search before filing. Read the contributing
+  guidelines before opening a pull request. Provide reproduction steps.
+- **Take responsibility for mistakes.** Apologize, correct, and move on. This
+  applies to maintainers at least as much as to contributors.
+
+## Unacceptable behavior
+
+The following are not tolerated in any project space:
+
+- Harassment of any kind, whether public or private, including unwelcome
+  attention after a request to stop.
+- Insults, personal attacks, and derogatory comments, including those directed
+  at a person's employer, nationality, or perceived level of expertise.
+- Discriminatory language or conduct relating to age, body size, disability,
+  ethnicity, gender identity or expression, level of experience, nationality,
+  personal appearance, race, religion, or sexual identity or orientation.
+- Sexualized language or imagery, and sexual attention of any kind.
+- Publishing another person's private information, such as a home address, a
+  personal email address, or an employer's internal information, without their
+  explicit permission.
+- Sustained disruption of discussion, deliberate intimidation, or trolling.
+- Advocating for or encouraging any of the above.
+
+Two clarifications, because this is an engineering project and the line is
+sometimes drawn in the wrong place:
+
+**Technical disagreement is not harassment.** Rejecting a pull request,
+questioning an approach, insisting on evidence, or holding a contribution to the
+project's conventions are all legitimate and expected. A contributor whose work
+is declined has not been mistreated.
+
+**Persistent, targeted hostility is harassment even when it is dressed as
+technical critique.** The distinction is whether the conduct is directed at the
+work or at the person.
+
+## Conflicts of interest
+
+CIMTool contributors frequently work for organizations that compete with one
+another, and some contribute to standards that CIMTool implements. This is
+normal and welcome. It becomes a problem only when it is concealed.
+
+If you have a commercial or standards-related interest in the outcome of a
+technical decision, disclose it on the relevant issue or pull request. Using the
+project to advantage an employer, disparage a competitor, or steer an
+implementation away from the published standard is unacceptable.
+
+Using CIMTool in the course of your work, and filing enhancement requests that arise
+from that use, is not a conflict of interest and requires no disclosure. It is how
+the project learns what it is missing, and requests of this kind are welcome from
+every organization, the corporate sponsor included. They are judged on their merits
+alongside all others. The disclosure obligation concerns an interest in the
+*outcome* of a decision that is separate from the merits of the tool itself: a
+commercial stake in one resolution over another, or a position in a standards body
+that the decision would affect.
+
+## Security and responsible disclosure
+
+Publicly disclosing a security vulnerability in CIMTool before maintainers have
+had a reasonable opportunity to respond is a violation of this Code of Conduct. The
+cost of a premature disclosure is not borne by this project. It is borne by the
+organizations running CIMTool in production, who have no fix to apply and no warning
+that they need one.
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for how to report a vulnerability
+privately.
+
+## Reporting
+
+If you experience or witness behavior that violates this Code of Conduct, report
+it to the project maintainers at
+[cimtool-conduct@ucaiug.org](mailto:cimtool-conduct@ucaiug.org).
+
+Include, as far as you are able:
+
+- What happened, and where. Links to the relevant issue, pull request, or
+  comment are the most useful thing you can provide.
+- Whether the conduct is ongoing.
+- Any context you believe is relevant, including prior incidents.
+
+You do not need to be the target of the behavior to report it.
+
+**If your report concerns a project maintainer**, or if for any reason you are
+not comfortable using that address, contact the UCAIug directly at
+[github.admin@ucaiug.org](mailto:github.admin@ucaiug.org).
+
+## Confidentiality
+
+Reports are treated as confidential. We will not disclose the identity of a
+reporter without their consent, except where we are legally obliged to do so, or
+where a person's safety is at immediate risk.
+
+We will acknowledge a report promptly and tell you what we intend to do. We may
+not always be able to tell you the outcome, since the subject of a report is
+also entitled to a degree of privacy.
+
+Reporting in bad faith, whether to retaliate against someone or to manufacture a
+grievance, is itself a violation of this Code of Conduct.
+
+## Enforcement
+
+Maintainers are responsible for clarifying and enforcing this Code of Conduct.
+They may edit, hide, or delete comments, commits, code, issues, and pull
+requests that violate it, and will explain their reasoning when they do so.
+
+Responses are proportionate. In escalating order:
+
+1. **Private correction.** A private message explaining what was wrong and why.
+   Most incidents end here, and most people who receive one adjust.
+
+2. **Warning.** A formal warning, with consequences stated. This may include a
+   period during which the person is asked not to interact with those involved,
+   including in project spaces and unsolicited outside them.
+
+3. **Temporary suspension.** A defined period without participation in project
+   spaces. Contributions submitted during a suspension will not be reviewed.
+
+4. **Permanent exclusion.** Reserved for sustained violation, harassment of an
+   individual, or aggression toward a class of people. This is rare and it is
+   final.
+
+Maintainers who violate this Code of Conduct face the same consequences as
+anyone else, escalated rather than mitigated by their position. A maintainer who
+cannot be held to the standard they enforce should not be a maintainer.
+
+## Appeals
+
+A person subject to enforcement action may appeal by writing to
+[github.admin@ucaiug.org](mailto:github.admin@ucaiug.org) within thirty days,
+setting out why they believe the action was mistaken or disproportionate. The
+appeal will be considered by someone who was not involved in the original
+decision.
+
+## Attribution
+
+This Code of Conduct is original to the CIMTool project. It draws on ideas
+common to the [Contributor Covenant](https://www.contributor-covenant.org/) and
+other widely adopted community standards, and it is offered under the same terms
+as the project itself.
+
+Suggestions for improving it are welcome. Open an issue.