Apache Polygene™ is a community based on open development principles
The Apache Polygene™ community is an open source community centered around software and components for Composite Oriented Programming on Java/Scala, and related design methodologies that are enhanced by using Apache Polygene™, like Domain Driven Design, DCI (Data, Context, Interaction) and HATEOAS REST.
The Apache Polygene™ community is an open community, in so far as it welcomes any member that accepts the basic criteria of contribution and adheres to the community's Code of Conduct.
Note that you can contribute to Apache Polygene™ also by contributing documentation or giving feedback on the current documentation. Basically, at all the places where you can get help, there's also room for contributions.
email@example.com mailing list
To discuss with the Apache Polygene™ community, it is easiest to do so at the firstname.lastname@example.org mailing list. This list is open to everyone and regular open source forum etiquette applies. Failure to be respectful may cause the poster to be expelled. The forum is a light and friendly one, where we are all friends working on a marvelous way of writing Java code.
Principles of Participation (not enforced yet)
We borrow a lot of our principles in community building from OPS4J, as OPS4J was the initial home of Apache Polygene, called Qi4j back then. OPS4J is unique that it allows everyone to participate and modify the codebase without being voted into the community. We want to retain the spirit of this openness and low-barrier of entry, but need some structure to organize ourselves.
There is a social agreement among the community members that we should try to communicate our intent as much as possible, but not be held back from doing things, just to get approval for the changes. Reverting changes are easy in GIT, so a Commit-Then-Review policy is in effect. Individual changes can be vetoed, and the veto comes with a motivation to be valid, and for additional features or bug fixes, the veto needs to provide an alternative solution within two weeks. The veto stands either until the person who cast the veto withdraws it, or for two weeks and no alternative solution has been presented. We think this strikes a good balance between progress and avoidance of catastrophic changes.
I want to help, what do I do?
First of all, subscribe to email@example.com and introduce yourself. Secondly, take a look at the outstanding JIRA issues and see if there is anything that you are capable of working on. Communicate that with the community. If there is no issues, that you can manage, consider creating your own JIRAs, such as working on the Getting Started guide or more test cases.