## Ideas for eXist-db org app repos
Incomplete, draft notes toward a proposal for a consideration by the community during a future community call
### Goals
- Have a common set of best practices for maintaining and releasing quality eXist community apps
- Help maintainers know what they should do
- Help users know how to report problems, ask questions, and contribute
- Help the community stay aware of releases
### Ideas
- Identify "steward(s)" for each app, who take primary responsibility for maintaining the app (triaging issues, assigning PR reviews, preparing releases)
- Priority for this is on "core apps": packages included in default distribution
- Versioning
- Version number is listed in build.properties or pom.xml
- Follow the eXist semantic versioning policy
- Releases
- Put release notes in repo.xml (or maven equivalent)
- Decide on whether release notes order is ascending or descending
- Add a git tag for the release commit
- Publish the .xar as a release in GitHub using the git tag for the release commit
- Publish the .xar in the eXist Public Repo
- Repo style guide
- Repo name should avoid "exist-\*" prefixes. The org name suffices to announce the eXist identification.
- README.md
- Start with "##" and full app name
- Provide a brief summary, followed by build instructions
- List the current steward(s)
- Integrations with HipChat eXist-db/integrations room
- Adding a hook to https://github.com/eXist-db/exist/settings/hooks will send notices of issues, commits, etc.
- Core apps with TravisCI integrations should add a directive like https://github.com/eXist-db/exist/blob/develop/.travis.yml#L11-L12