About the Community

Community Organization

Our community is made up of individuals and groups who share the common goal of advancing Apache IoTDB, who subscribe to the open source culture, and who follow the relevant specifications.
Referring to the Apache Software Foundation's community philosophy, our community has four roles.

• PMC Member: A committer of the Project Management Committee. A PMC member was elected due to merit for the evolution of the project.
  • Rights:
    • Vote on major project decisions
    • Receive recognition and awards
    • All the rights of a Committer
  • Duties:
    • Provide essential support for project development and community events
    • Guide the project's open-source advocacy and future direction
    • All the duties of a Committer
• Committer: A member of the community who helps the project to move forward. The election process must be agreed upon by the community.
  • Rights:
    • Pull Request approve permission (binding)
    • Merge Pull Request permission
    • Release new version rights
    • Get recognition and awards.
  • Duties:
    • Actively participate in project discussions and provide advice on major decisions
    • Community support
    • Community development or outreach task support
• Contributor: community members who have a relevant contribution to the project moving forward. No need to go through the election process.
  • Rights:
    • Pull Request approve permission
    • Receive recognition and awards
• User: A user of the Apache IoTDB project. No election is required.

Community Election Rules

PMC

• Get recommendations from existing PMC members
• Technical Expertise:
  • Have a comprehensive understanding of the program
• Development Insight:
  • Deep insight into the time-series database industry and the ability to grasp the direction of the project
• Cultural Alignment:
  • Have a strong sense of open source culture, and contribute to the open source software advocacy

Committer

• Get recommendations from the existing PMC members
• Development Path
  • Need to have complete understanding of a functional module
• Open Source Evangelist Path
  • Contribute substantially to the open source advocacy of the project, e.g., contribute to technical documentation, provide and present user stories, actively participate in community exchanges and activities, etc.
• To understand the Apache Software Foundation's Code of Conduct (See ASF Documentation) In particular, they are committed to:
  • Be open
  • Be empathetic, welcoming, friendly, and patient
  • Be collaborative
  • Be inquisitive
  • Be careful in the words that we choose
  • Be concise
  • Step down considerately
• Adhere to the responsibilities of an Apache Software Foundation’s committer (See the ASF documentation)
  • Help create a product that will outlive the interest of any particular volunteer, including themselves
  • Maintain the health of the Apache community and help it grow
  • Decide on release plans and releases
  • Apply patches
  • Help users
  • Monitor commits and issues
  • Help out with the website
• Practices that strengthen the IoTDB community
  • Have a strong commitment to the project
  • Share ideas with the community
  • Take community feedback and integrate it into plans, designs, code, etc
  • Be serious about trying to make IoTDB better through contributions
  • Especially, if code contributors:
    • are serious about trying to make IoTDB better through their code
    • are serious about trying to make the IoTDB better through code reviews
    • accept and integrate feedback about their code
    • understand, adhere to, and continually optimize IoTDB best practices when reviewing/merging code (styles, documentation, tests, backward compatibility, etc.)

Contributor

• Set up a development platform account:
  • Create a Jira account: https://issues.apache.org/jira/projects/IOTDB/issues to claim an issue.
  • Create a Confluence account: https://cwiki.apache.org/confluence/display/IOTDB/Home. This will be used to write the design documentation.
    Once created, send an email to the mailing list with Introduction and Jira ID and Confluence ID and the community PMC will add permissions to the account.
• Long Term Matters:
  • Learn how to debug IoTDB
    • How to debug IoTDB server
  • Understand the basics of using IoTDB
    • IoTDB download and installation
    • IoTDB Quick Start Guide
    • Data Schema and Concepts
    • API Interface
  • Understand IoTDB's Internal Design
    • IoTDB Design Documentation
  • Finding tasks to be done
    • Resolving Issues on Jira

Code of Conduct in the Apache Community

According to the Apache's community culture (See ASF Specific Guidelines), the following covenants are formed.

1. Be open. We invite anyone to participate in our community. We prefer to use public methods of communication for project-related messages, unless discussing something sensitive. This applies to messages for help or project-related support, too; not only is a public support request much more likely to result in an answer to a question, it also makes sure that the community notices and corrects any inadvertent mistakes people answering the query may make.

2. Be empathetic, welcoming, friendly, and patient. We work together to resolve conflicts, assume good intentions, and do our best to act in an empathetic fashion. We may all experience some frustration from time to time, but we do not allow frustration to result in a personal attack. A community where people feel uncomfortable or threatened is not a productive one. We should be respectful when dealing with other community members as well as with people outside our community.

3. Be collaborative. Other people will use our work, and we in turn depend on the work of others. When we make something for the benefit of the project, we are willing to explain to others how it works, so they can build on the work to make it even better. Any decision we make will affect users and colleagues, and we take those consequences seriously when making decisions.

4. Be inquisitive. Nobody knows everything! Asking questions early avoids many problems later, so we encourage questions, although we may redirect them to the appropriate forum. Those who receive a question should be responsive and helpful, within the context of our shared goal of improving Apache project code.

5. Be careful in the words that we choose. Whether we are participating as professionals or volunteers, we value professionalism in all interactions, and take responsibility for our own speech. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behaviour are not acceptable. This includes, but is not limited to:

   • Violent threats or language directed against another person.
   • Sexist, racist, or otherwise discriminatory jokes and language
   • Posting sexually explicit or violent material.
   • Posting (or threatening to post) other people's personally identifying information ("doxing").
   • Sharing private content, such as emails sent privately or non-publicly, or from unlogged forums such as IRC channel history.
   • Personal insults, especially those using racist or sexist terms.
   • Unwelcome sexual attention.
   • Excessive or unnecessary profanity.
   • Repeated harassment of others. In general, if someone asks you to stop, then stop.
   • Advocating for, or encouraging, any of the above behaviour.

6. Be concise. Keep in mind that, over time, hundreds or thousands of people will read what you write. Writing a short email means people can understand the conversation as efficiently as possible. Short emails should always strive to be empathetic, welcoming, friendly and patient. When a long explanation is necessary, consider adding a summary at the top of the message.

   Try to bring new ideas to a conversation so that each email adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made.

   Try to stay on topic, especially in discussions that are already fairly long.

7. Step down considerately. Members of every project come and go. When somebody leaves or disengages from the project they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off. In doing so, they should remain respectful of those who continue to participate in the project and should not misrepresent the project's goals or achievements. Likewise, community members should respect any individual's choice to leave the project.

Release Management

Release Manager

A committer is designated as the release manager that responsible for the mechanics of the release. The release manager oversees the process from initial consensus to final code distribution and may publicize the release to the community and ASF.

Process Overview

There are two main roles in the release process.

• Role A: The RM (Release Manager) is the person who initiates the release. Typically, this role is performed by a single person rather than multiple people.
• Role B: Community Developer. The community developers will vote on whether or not to release a new version. It is worth reminding that not all community developers are forced to vote on the release of a new version.

In our open source community, releasing a new version is done in five main steps.

• Step 1: The RM initiates a proposal. RM (Release Manager) sends out the proposal by email. The emailed proposal will fully describe the improvements of the new release.
• Step 2: Community developers review the proposal. Once the community developers received the email, they can reply to the email to clarify their suggestions or questions about the proposed new release. If they agree with the proposal, they do not need to reply to the email.
• Step 3: RM stages a Release Candidate. Once the community developers' suggestion has been fully considered, the RM will stage the Release Candidate via email for the developers to test and vote.
• Step 4: Community developers vote on the Release Candidate. Community developers get the Release Candidate and test it. After testing, a vote is taken via email.
• Step 5: Upon approval, the RM releases the official version and announces it. When the voting results meet the prescribed situation, RM releases the official version and announces it to the public via email. (If the vote fails, the RM will announce the failure of the release via email and will modify and re-initiate the process of releasing the new version.)

Frequently Asked Questions

Question 1: How do community developers validate new releases?

Please see https://iotdb.apache.org/zh/Development/VoteRelease.html;

Question 2: What are the criteria for approving a poll?

According to the instructions given by the Apache Software Foundation (ASF Release Policy), we will leave the voting window open for 72 hours or more. When at least three PMC members approval votes are received and there are more approval votes than disapproval votes, the vote passes. The RM will summarize the results of the poll and announce the results via email.

Question 3: Is there a detailed guide for new RMs?

For new RMs, we provide detailed hands-on instructions. For a detailed description of what you need to do at each step, please see the "Release Management" section on this page.