Your contribution is always welcome! Please make sure to read this document which aims to help you to contribute in a way that makes it easier to bring your changes into this project.
There are many things you can do to help to improve Scrum Poker for Jira:
- Create issues for new features or improvements
- Provide new translations for this app or improve existing ones
- Add test coverage for untested code
- Refactor the code
- ...
Development of Atlassian Jira plugins is closely bound to the Atlassian Plugin SDK. Setting up your development environment is documented here: Set up the Atlassian SDK and build a project
During development you will find the following commands useful:
atlas-run
installs this plugin into Jira and starts it on localhostatlas-debug
same as atlas-run, but allows a debugger to attach at port 5005atlas-package
to generate a Jar file of the plugin which can be installed into your Jira instanceatlas-clean
to clean up thetarget
folder and so allow you to start with a clean Jira instance again
Reloading the plugin during development can be triggered in your web browser when hitting Shift + Reload
(for example Shift + Cmd + R
on Mac OS X).
From time to time it makes sense to check the dependencies required to build and run Scrum Poker for Jira. There are two maven commands that should be run and verified:
mvn dependency:analyze
analyzes the dependencies of this project and determines which are: used and declared; used and undeclared; unused and declared returns a list of used but not declared and a list of declared but not used dependencies. Not all results require actions since there can be dependencies not being resolved on bytecode level.mvn versions:display-dependency-updates
analyzes the dependencies of this project and lists all dependencies that exist in one of the configures repositories in a more recent version than the one being used. There are many false positives since versions are only compared based on the version number and there are many dependencies with irrelevant version numbers.
Commit messages should be written in this format:
<type>: <subject>
<body>
<footer>
The first line put together from the type
and the subject
should not be longer than 70 characters, the second line is always blank and the following lines should be wrapped at 80 characters.
- feat (new feature)
- fix (bug fix)
- docs (changes to documentation)
- style (formatting, missing semi colons, etc; no code change)
- refactor (refactoring production code)
- test (adding missing tests, refactoring tests; no production code change)
- chore (updating dependencies etc; no production code change)
- uses the imperative, present tense: “change” not “changed” nor “changes”
- includes motivation for the change and contrasts with previous behavior
The message footer is used to reference issue that are addressed and closed by this commit. Closed issues should be listed on a separate line in the footer prefixed with "Closes" keyword like this:
Closes #17
or in case of multiple issues:
Closes #17, #18, #19
feat: users cannot see sessions for issues without permission
Adds a check to prevent users to see issues they are not allowed to see. Prior
to this commit users were able to open sessions and see details for issues
that they are not allowed see in Jira directly.
Closes #17
Releasing a new version helps to bring out new features and improvements to our customers. To keep track of all changes we do the following:
- update the Changelog with the release date
- update the POM file with the new version number
- update the Compatibility Matrix with the new version number
- create a tag for the new version with reference to the latest commit
git tag -a <version> -m "<version>" <commit hash> git push origin <version>
- upload and promote the new version at Atlassian Marketplace
- Contributing code by Elmar Jobs and Stefan Höhn
- Inspiration for Contributing page by Karma
- Inspiration for Changelog page by Keep a Changelog
- Intensive testing and feedback by congstar GmbH