Arches® Open Source Community Code of Conduct

Version 2.0 (dated March 25, 2020)

This Code of Conduct provides guidance for those wishing to participate in the Arches open source community, as well as steps to reporting unacceptable behavior. We are committed to providing a welcoming and inspiring community for all and expect our code of conduct to be honored. Anyone who violates this code of conduct may be banned from the community.

You may navigate the Code of Conduct by the following sections:

• Guidelines for Participation in the Arches Open Source Project
• Guidelines for Commercial Entities and Others Deploying Arches
• Arches Trademark Policy and Branding Guidelines
• Reporting Code of Conduct Issues

Guidelines for Participation in the Arches Open Source Project

The Arches open source community strives to:

Be friendly and patient.
Be welcoming: We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.
Be considerate: Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we’re a world-wide community, so you might not be communicating in someone else’s primary language.
Be respectful: Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one.
Be careful in the words that we choose: we are a community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren’t acceptable.
Try to understand why we disagree: Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Remember that we’re different. The strength of our community comes from its diversity, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.

General Guidelines for Commercial Entities and Others Deploying Arches

The Arches project welcomes involvement from commercial and other entities. The availability of multiple sources of commercial support is important to the project’s long-term health, and to making Arches a persuasive choice for organizations around the world. Commercial support can include but is not limited to installation, hosting, on-site deployment and installation, help-desk services, maintenance, training, customization, and development of new features.

While the specific items in the guidelines that follow may be revised from time to time, overall the guidelines are based on a simple principle:

Those deploying Arches should observe the distinction between public community functions and private commercial functions, and ensure that their activities support (or at least do not harm) the public community.

Treat the Arches name with respect, and follow the project’s trademark and branding policy.
In particular, don’t seize the Arches name in other public namespaces, e.g., company names, names of commercial service offerings, in domain names, Twitter, GitHub, Slack, etc.It is reasonable, however, to register the project’s name in a new namespace and then immediately donate control of that account to the project, because that is helping the project maintain its identity.For further guidance, see the Arches Trademark and Branding Policy that follows.
Don’t replace community infrastructure; instead, improve it.
For example, use the Arches discussion forum, instead of setting up duplicate forums in a privately-controlled space that could potentially siphon off people from the existing Arches forum. In other words, don’t set up “walled gardens” that detract from public spaces. The same principle also applies to other kinds of community infrastructure such as project documentation, which is mentioned in more detail elsewhere in this document.It is fine to set up private forums that are specific to your commercial offerings, especially where those offerings differ from what is available in the open source project (though see the next item about avoiding the “enterprise edition” trap). That is, discussion that is specific to your commercial offering and is only useful to your customers. But do not discourage your customers from making use of the project’s public forum when doing so would serve their needs.A good way to ensure compliance with this guideline is to link to the relevant project forums from the same places — and in comparable ways — that you link to your product-specific forums. That way customers will be aware of all the options available to them and can choose the appropriate forum for their needs. It also means that your customers’ questions, and yours or others’ responses to them, can contribute to the public store of knowledge about Arches, which is an important way that your commercial activity can support the long-term health of the project. Your representatives should include their affiliation in any support responses they make to customers or to anyone else. Your company should get credit for your contributions.
Label your offerings in a way that makes their provenance clear, and that does not denigrate or diminish the Arches open source project.
Specifically, do not label your proprietary offering as the “Commercial Edition” or “Enterprise Edition” of Arches, especially not in contrast to a so-called “Community Edition” as a euphemism for the Arches project’s open source code. That kind of marketing implies that the open source edition is somehow not commercial (which would be untrue, as the open source license explicitly allows commercial activity by anyone) or not enterprise-ready (unlikely to be true, but in any case ill-defined). Instead, give your offerings their own distinctive names. If those names incorporate “Arches” in some way, that may be acceptable so long as it complies with the project’s trademark guidelines. It is also reasonable to offer fact-based comparisons between your proprietary offering and the stock open source version, or between your offering and others’ proprietary offerings. Or if your offering is also open source software, but differs from the project’s offering in some significant way, explain that, and again make sure your offering has a name that clearly distinguishes it from the code released by the Arches project.The purpose of this particular guideline is to help you communicate clearly about what your company or other entity offers, and to help potential customers understand what differentiates your offerings from what is available elsewhere. There is nothing wrong with offering features not present in the project’s open source releases, or with making different configuration choices from the project’s defaults. Just describe the differences accurately and objectively. Mislabeling, whether accidental or deliberate, causes confusion and is bad for the Arches project’s health.
Do not attempt to convert unofficial influence into claims of official control.
Even if your company or project is a major contributor to Arches, do not conflate the project’s identity with your own. If a company with a well-established position in the project casts too large a shadow, it may discourage involvement from others.
For example, your company might have a number of employees as core committers in the project, and thus exercise a significant de facto influence over the project roadmap, simply by doing a lot of the work and participating actively in project development discussions. This is generally not a problem, as long as you do not claim some official preferential position in project governance that you do not in fact hold.
In public forums, your employees should behave like any other project participants.
While your management hierarchy may be important internally to your company or organization, it is irrelevant to the public open source project. For example, if you assign an employee specifically to work on Arches, expect that employee’s contributions to still go through the usual review procedures, and expect that employee to gain commit access by the same route as anyone else would. Similarly, it is good practice for your employees to hold design discussions or other technical discussions in the Arches public development forums, even if the employees normally sit in the same room and could discuss those things in person. The more they participate visibly in the project, the stronger the ties between your company and Arches will be.
Contribute to public activity, and avoid converting public conversations to private ones.
When commercial representatives are active in an open source project’s public forum, there will be many opportunities to turn public conversations into sales opportunities. This can be a good thing — often a potential customer will benefit from being contacted about a commercial offering, and commercial entities should feel free to establish such contact so long as they avoid harassing or spamming people. In general, if someone indicates needs that would be met by your product, it is reasonable to contact them about that directly, as long as you are respectful of the Arches forum rules, and respectful of any preferences they may have given about unsolicited commercial communications.However, it is important to avoid shunting conversations out of the public Arches forum, where inquiries and responses will remain visible to others, and into private forums, where the initiator would be isolated from other sources of information. The best way to avoid this anti-pattern is to distinguish carefully between answering questions and offering commercial services. The former should always be done via a public followup in the Arches forum where the question was asked, while the latter should happen via a separate private communication. A topic that started in public should remain public, and should not be interfered with or subsumed by private conversations.
Improve project documentation, don’t fork it.
Help make the Arches project’ public documentation better, rather than duplicating and extending that documentation elsewhere. Even if your duplicate documentation is publicly accessible to non-customers, it will still detract by its mere existence from the Arches project’s own documentation, by, among other things, causing confusion in Internet search engine results.It is fine to maintain separate documentation for functionality that is specific to your product or service. But as much as possible, avoid duplicating material already present in the Arches documentation. Instead, refer to the Arches project’s documentation, and, as much as necessary, participate in improving it and making it easier to refer to, so that your maintenance burden and everyone else’s is reduced.
Non-compete agreements may restrict business activity, but not project activity.
If your company requires employees or contractors to sign non-compete agreements, those agreements must not prevent the individual in question from participating in the Arches open source project in any way, whether during or after the term of their employment.This does not mean that all non-compete agreements are incompatible with this code of conduct. A company may restrict an employee’s ability to solicit the company’s customers, for example. The key is that any restrictions should be about things other than Arches project participation itself. An individual should not be blocked from any form of technical or social participation in the Arches project, including the implementation of particular features.The accumulation of experience and expertise in individual persons, who are ultimately free to direct their energy and attention as they decide, is one of the most important drivers of progress in open source projects. A company that limits this freedom can hinder the success of the Arches project.
Security vulnerability information should always be promptly disclosed to the Arches project.
If a commercial entity learns about a security vulnerability in the Arches open source code, it should always promptly disclose that information to the Arches project. Security vulnerability information should be reported at: archesproject.org/security-reporting-form. (Of course it is acceptable to pre-patch the company’s own offerings, as long as that patching does not significantly delay the reporting of the vulnerability.)Vulnerability information should never be used for unilateral commercial advantage. Vendors may legitimately compete on the speed and reliability with which they deploy security fixes, but withholding vulnerability information damages everyone in the long run by risking harm to the Arches project’s reputation and the security of all users.
Let your commercial priorities guide your developers’ priorities in the project.
There is no need to hide motivations in an open source project. It is very normal for developers to propose that a certain capability be added to the code and justify the proposal on the grounds that it would help their employer’s commercial interests. As long as the proposed change goes through the project’s usual decision-making procedures, the fact that it would serve specific commercial interests is not only not bad for the project, it may often be good: after all, continued commercial interest in the code is usually a good thing.Of course, it would be odd to make a technical proposal that is wildly divergent from the Arches project’s current roadmap and from the interests of all other parties participating in the project, but in that case the proposal is likely to be rejected anyway. In general, there is no need to pretend to purity of motivations. Finding sustainable resolutions to the tensions between various parties’ needs is a long and well-established tradition in open source projects; as long as you participate in those discussions in good faith, and compromise where appropriate, the influence of your commercial motivations is likely to be an overall benefit to the project.

Arches Trademark Policy and Branding Guidelines

The Arches trademarks, including the Arches name and logos, are owned by the J. Paul Getty Trust and World Monuments Fund. The Arches trademarks are subject to the J. Paul Getty Trust Trademark Policy for Open Source Projects and the Arches project team is working on creating Branding Guidelines to accompany this policy. In the meantime, please send questions to the Arches project at: contact@archesproject.org.

The Arches Branding Guidelines are for anyone using the Arches brand assets (logo, icon and word marks) for Arches specific dissemination and communications (digital and print).

Reporting Code of Conduct Issues

We encourage members of the Arches community to resolve issues on their own whenever possible.
If you believe that the Arches Community Code of Conduct is being violated and you are unable to resolve the issue, please feel free to report your concerns by contacting the Arches project team at: contact@archesproject.org. Your report will be addressed as soon as possible.

All reports will be handled with discretion. In your report please include:

Your contact information.
Names (real, nicknames, or pseudonyms) of any individuals involved. If there are additional witnesses, please include them as well. Your account of what occurred, and if you believe the incident is ongoing. If there is a publicly available record (e.g. a mailing list archive or a public IRC logger), please include a link.
Any additional information that may be helpful.

After filing a report, the Arches project team will contact you personally, review the incident, follow up with any additional questions, and make a decision as to how to respond. Where additional perspectives are needed, the team may seek insight from others with relevant expertise or experience. Parties involved in the report are never part of the team reviewing the alleged violation.

Anyone asked to stop unacceptable behavior is expected to comply immediately. If an individual engages in unacceptable behavior, the Arches project team may take any action they deem appropriate, including a ban from the community.

Acknowledgements

Much of this code of conduct, particularly its guidelines for commercial entities, was prepared by Open Tech Strategies, which advises the Arches project on open source issues. Its general guidelines for participation are based on the template established by the TODO Group and used by numerous other large communities (e.g., Facebook, Yahoo, Twitter, GitHub).