Become one of the contributors! We thrive to build a welcoming and open community for anyone who wants to use Mongoose via the Web UI or contribute to it. Here we describe how to contribute to any of the {code} projects.
Please, note that all contributors shall follow the Contributor Agreement guidelines provided here.
- Contributors
- Versions
- Issues
3.1. States
3.2. Specific properties - Code
4.1. Performance
Alphabetically:
The following interfaces are mentioned as the subject of the backward compatibility:
- Input (item list files, scenario files, configuration options)
- Output files containing the metrics
- API
Darzee uses the semantic versioning. This means that the X.Y.Z version notation is used:
- X
Major version number. Points to significant design and interfaces change. The backward compatibility is not guaranteed. - Y
Minor version number. The backward compatibility is guaranteed. - Z
Patch version number. Includes only the defect fixes.
Types:
- Defect
- Story
- Task
- Sub-task
| Type | Description |
|---|---|
| Defect | The defect/bug which affects the released version (the type "Task" should be used if a defect/bug affects the version which is not released yet) |
| Story | High-level use case or a long-term activity aspect (entirely new page, a complicated UI component, integration with external services, etc.) |
| Task | A task which couldn't be included into any defect/story |
| Sub-task | A task which could be included into a defect/story |
Darzee's tracker link: https://mongoose-issues.atlassian.net/projects/GUI
| State | Description |
|---|---|
| OPEN | All new issues should have this state. The issues are selected from the set of the OPEN issues for the proposal and review process. The task is updated w/ the corresponding comment but left in the OPEN state if it's considered incomplete/incorrect. Also incomplete/incorrect issue should be assigned back to the reporter. |
| IN PROGRESS | The issue is in progress currently either initially done and the corresponding merge request to the master branch is created |
| RESOLVED | Issue is done and the corresponding changes are merged into the master branch |
| CLOSED | The new version is released containing the corresponding changes |
Note:
The corresponding impact probability/frequency is not taken into account in the process currently. For example, all defects are assumed to be equally frequently occurring and affecting same users, regardless the particular scenario/use case. This approach is used due to the lack of the sufficient statistical information about the Mongoose Web UI usage.
| Name | Applicable Issue Types | Who is responsible to specify | Notes |
|---|---|---|---|
| Affected version | Defect | Reporter: user/developer/owner | Only the latest version may be used for the defect reporting. The issue should be rejected if the reported version is not latest. |
| Branch | Defect, Task, Sub-task | Reviewer: developer/owner | |
| Description | Task, Sub-task | Reporter: user/developer/owner | |
| Expected behaviour | Defect | Reporter: user/developer/owner | The reference to the particular documentation part describing the expected behavior is preferable. |
| Fix version | Defect, Task, Sub-task | Reviewer: developer/owner | |
| Limitations | Story | Reviewer: developer/owner | |
| Observed behaviour | Defect | Reporter: user/developer/owner | Error message, errors.log output file, etc. |
| Pull request | Defect, Task, Sub-task | Reviewer: developer/owner | |
| Resolution commit | Defect, Task, Sub-task | Reviewer: developer/owner | |
| Root cause | Defect | Reviewer: developer/owner | |
| Start command/request | Defect | Reporter: user/developer/owner | Leave only the essential things to reproduce: try to check if possible if the bug is reproducible w/o distributed mode, different concurrency level, item data size, etc. |
| Steps | Defect | Reporter: user/developer/owner | |
| Purpose | Story | Reporter: user/developer/owner | Which particular usage of Mongoose should be changed / included within the UI? Related mock ups, screenshots or a detailed discription of the requested feature are encouraged. |
| Requirements | Story | Reporter: user/developer/owner | Both functional and performance requirements are mandatory. Optionally the additional requirements/possible enhancements may be specified. |
Take care about the performance in the critical places:
- Avoid frequent objects instantiation
- Avoid unnecessary frequent allocation
- Avoid frequent method calls if possible
- Avoid deep call stack if possible
- Avoid multiple component / modules reload
- Avoid unnecessary component observers and their calls
- Use services for REST API calls