Draft for Guidelines for communication about Operaton

During the last townhall meeting we discussed putting “Communication & Interaction” as one of our principles on the new homepage. @javahippie startet the discussion on Slack with the following principles he uses for his company. Do we want to adopt these principles for our communication (blog posts, linkedin posts, etc…) regarding Operaton?

Tim’s proposed principles:
Core Branding Objectives

  1. Excellence in Technical Proficiency:
  • We pride ourselves on possessing and continually developing strong technical skills.
  • Our team is composed of highly skilled professionals committed to technical excellence.
  1. Flexible and Open Technological Approach:
  • We maintain a non-dogmatic stance on various technologies.
  • Our philosophy is to remain open-minded and adaptable in our technological choices.
  1. Advocacy for Simplicity in Software Solutions:
  • We are staunch advocates for simple, yet effective software solutions.
  • Our approach is to tailor software complexity to match the intricacies of each specific use case.
  1. Commitment to Inclusivity:
  • An inclusive mindset is at the heart of our company culture.
  • We actively promote diversity and inclusivity in our workplace and in the solutions we create.

Key Principles for Public Communication

  1. Inclusivity and Respect:
  • We strictly avoid making jokes or generalized statements about any group, particularly minorities.
  • Our content is free from discrimination based on gender, age, ability, or any other form.
  1. Professionalism in Critique:
  • We refrain from negative commentary about individuals or groups.
  • Avoid statements like “Many companies do it wrong when…” or personal critiques such as “This blog post is misguided.”
  1. Objective Technology Discussion:
  • Our discussions about technology are unbiased and constructive.
  • Avoid broad negative statements like “Kubernetes is overengineered” or “PHP is poorly designed.”
  • Instead, we offer balanced views, such as “For small-scale applications, Kubernetes might not be the most suitable choice.”
  1. Respect for Innovation and Creators:
  • Acknowledge the efforts of those who develop and use various technologies.
  • Understand that criticizing a technology can indirectly affect its community of users and creators.
  1. Evidence-Based Arguments:
  • Discussions about technologies or approaches are grounded in concrete experience or research.
  • Avoid unsupported claims like “X is obviously better.”
  • Encourage statements backed by experience, such as “Using technology X reduced development time by 20% in our project.”
  • Cite credible research where applicable, e.g., “As per [research paper], approach B can be beneficial in this context.”
2 Likes

I could very well identify with this rgd. my work on Operaton.

The points below “Advocacy for Simplicity in Software Solutions” are more targeted to providing services. This should me more tailored to the product.

We have already a Code of Conduct set up. This here aims in the same direction. Likely both can be merged, or the CoC updated.

1 Like

I would reference the CoC in the web apps repo as well. Assuming that we keep the code bases split, we still want to live by the same standards and avoid multiple sources of truths / duplication.

1 Like

IMO such rules/manifesto better fit a legal entity (a company) than an open source project.

Thanks for bringing this up.

Some additions/changes I would like to propose:

The phrase “Our team is composed of highly skilled professionals committed to technical excellence” could unintentionally sound exclusionary. Open-source projects like ours are strongest when they welcome contributors of all backgrounds and experience levels. Whether you’re an experienced developer, a junior analyst, or someone new to BPMN, there should be space to participate, learn, and grow here.

I propose reframing this to emphasize our community’s openness and commitment to learning. For example:

“Our project thrives on contributions from people of all skill levels and roles, united by a shared commitment to collaboration, learning, and continuous improvement. We welcome anyone passionate about improving BPMN solutions.”

BPMN involves much more than just technical expertise. Analysts, business users, and domain experts play a vital role in modeling and understanding processes. Our principles should reflect this diversity and acknowledge that Operaton isn’t just about technical solutions—it’s about building tools that empower all stakeholders.

Here’s a potential addition to address this:

“We recognize and value the diverse roles involved in BPMN, including analysts, business users, and technical contributors. Our goal is to create solutions and foster a community where everyone feels empowered to contribute, regardless of their background or expertise.”

Given these points, I’d suggest broadening the focus of “technical excellence” to include delivering reliable, use-case-driven solutions while maintaining openness to the contributions of all roles. For example:

“Our commitment to excellence extends beyond technical expertise to delivering reliable, practical solutions that address real-world use cases. We embrace contributions from all roles—technical or non-technical—that help us achieve this goal.”

By making these adjustments, we’re signaling that Operaton is not just for experts but for anyone who wants to contribute meaningfully. This inclusivity fosters a stronger, more diverse community, which is essential for a project like ours.

1 Like