We're inner source and we encourage your contributions! Contributions include:
- Documenting failing tests
- Providing patches with tests
- Submitting defect reports
- Defining and refining problem statements
- Feature/enhancement requests
✅ Contributions start with clear communication, and issues – not e-mails! – are the best way to collaborate with colleagues.
Besides, whenever you save a comment or an edit to an issue, the right stakeholders will be notified.
Think of issues communal to-do list. If you notice something wrong, toss an issue in and collaborate to determine when -- or whether -- it will be resolved.
🪲 If you believe you've encountered a defect -- aka a bug -- letting us know about it is a huge contribution. You can help by adding the following information as best you can.
1.1.1. Screenshots with a description showing the problem.
1.1.2. Console or server logs
1.1.3. Contact information of users who experienced this request
1.1.4. The time of the bug so that relevant logs can be found
The following things should always be included:
1.1.5. Enumerated steps to reproduce the issue
1.1.6. What happened when you followed those steps
1.1.7. What you expected to happen that didn't
📖 Share what you'd like improved, or even new features that would make your life easier.
If you'd like to see a new feature or enhancement:
1.2.1. Open a new Issue.
1.2.2. Add the following text:
As a
role, I must/need/want/shoulddo somethingIn order toachieve business value.
Assignees are responsible for completing an issue. Do not assign a person to an issue unless they agree to it.
Assign the issue to yourself or a willing and capable colleague! You can always clone the develop branch and issue a pull request to queue a code review.
The creation of new milestones is by group consensus only. Don't do it on your own.
A milestone with a due date should have a "responsible person" listed in the description. That doesn't mean that person is the sole person to work on it, just that they're the one responsible for coordinating efforts around that chunk of work. Once a milestone has a due date, only issues okay'd by the responsible person can be added. This ensures that a chunk of work can be delivered by the promised due date.
Issues require real people who balance work and life to review your issue, so don't label issues as "High" or greater unless they really apply.
"I want this new feature now" does not qualify as important. Generally, these labels should only be applied by people setting up a batch of work. Abusing priority labels only make the "Priority" meaningless.
Some good ways to make your issue isn't overlooked include: Appropriate labeling. A meaningful and succinct summary. E.g., if this is a browser bug, add the "browser" label, and prefix your issue title with the browser version and the URL you encountered the problem on. e.g. "IE 9: /wisps/xxx can't click on the search input" Screenshots are always handy.
Please scan the Backlog and active sprint for similar issues. If your issue is urgent, there might well be a "Hotfix" created already.
If you find your issue has already been reported, let your voice be heard! Vote for the issue Add meaningful comments to the existing issue "LIke" the issue to show your support.
TODO: list common style guidelines here.
W rite specs (i.e., unit tests). Behavior-driven development specifications are executable documentation. By the way, 100% code coverage is the norm, not the exception. :thumbs up:
Above all else, source code repositories communicate change to your colleagues and your future self! Therefore, please
Write meaningful commit messages that conform to the Angular conventional changelog preset.
Keep them somewhat short and meaningful. Commit messages like “meh”, “fix”, “lol” and so on are useless. Your are writing to your future self and everyone else. It’s important to be able to tell what a commit is all about from its message.
We use the Angular conventional changelog preset because it: Formats commit messages in a predictable, consumable way Allows us to automate updates to the product's CHANGELOG, which is as vital to communicating change as it is impossible for humans to do by hand.
Thank you for contributing, and welcome to the community!
Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.