-
Notifications
You must be signed in to change notification settings - Fork 133
Home
Welcome to the Dicoogle wiki!
| Name | Category | Description |
|---|---|---|
| master | Release's Branch | Dedicated to stable and tested releases |
| dev | Development Branch | Dedicated to tested functionality and new features |
| other branches | Dedicated to the remaining development stages |
Add your contribution to a separate branch
- Fork your contributions directly from the dev branch
- Always follow our branch naming conventions
- Always check for per-existing branches that might be suitable to hold your contributions
Do not merge your contributions directly to /dev or /master
- Always create a pull request, other peers will test and merge your contributions
- Pull requests should always target /dev
Each branch name is composed of the following:
category/name
The possible categories are listed below.
| Category | Description |
|---|---|
| bug | Bug fixing |
| imp | Improvement on already existing features |
| new | New features being added |
| wip | Works in progress - Big features that take long to implement and will probably hang there |
| junk | Throwaway branch, created for experimentations |
The name should be concise, and directly represent what the branch solves.
Some examples:
bug/issue234
bug/fixeditdb
new/statistics
junk/tryingboostrap3
The following list states a small description of this project's issue labels. All collaborators are advised to rely on these definitions.
-
bug: should be used for any anomaly present in the project -
enhancement: any improvement or optimization to existing features and code base can be labeled as an enhancement -
feature request: new features not previously established or planned can be posted with this label -
in progress: use this label on pull requests holding an incomplete solution, or for durable issues in the middle of development -
in discussion: used in issues containing a discussion on a particular feature or improvement, rather than a single well-defined proposal -
help wanted: can be used by a collaborator requesting for assistance in its resolution -
easy: used for issues that should be easy to resolve (good for undergraduates or outsiders to contribute to Dicoogle) -
feedback-request: can be used by an issue essentially formed by a request for feedback, such as a question, or one containing a matter that must be answered before any other procedure related to the issue can take place -
invalid: used for issues or pull requests that propose nothing relevant or useful to the project -
wontfix: used for no-problems or other issues that should never be fixed -
duplicate: similar toinactiveorwontfix, should be used for issues already being addressed in another one (a reference to the original issue should be included before closing).
The high priority, medium priority and low priority labels are disjoint and represent how important the issue is in the project. These are not mandatory and can be applied later on by a project maintainer or the development leader.
Furthermore, one should use dicoogle-core, sdk and webapp to categorize which component the issue concerns to.
Use UTF-8 character encoding for all source code. Some adjustments in your IDE of choice may be required.
All dependencies are managed through maven. Before adding a new dependency, make sure that the functionality is not listed in the Libraries section. We wish to avoid creating superfluous dependencies.
Use slf4j for all logging purposes, rather than interfacing with java.util.logging or log4j directly. All pieces of advice regarding the use of slf4j apply (see the FAQ).
Avoid performing concatenations in the logged text (e.g. logger.info("Status: " + status);), in favour of template matching (e.g. logger.info("Status: {}", status);).
Restrict ERROR level log instructions to situations where something critical occurred in the application, often associated to bugs in the software, and that should be attended by an administrator.