We're inner source and we encourage your contributions! Contributions include:
- Reporting defects (aka "bugs")
- Working on
Status: Availableissues - Adding detailed comments, documentation, or suggestions to
Openissues - Requesting new features or enhancements
- Submitting pull requests (PRs)
✅ 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. Uncomment the "User Story" sections in the pre-populated issue template.
As a
role, I must/need/want/shoulddo somethingIn order toachieve business value.
Selecting accurate label(s) communicates vital information about an issue.
This project enforces AngularJS Git Commit Guidelines with
commitpleasepre-commit hooks. This not only encourages succinct change logs, but also enables automated release management withsemantic-release.
Issues related to product builds. The AngularJS Git commit message format is
build(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
Issues related to miscellaneous non-functional changes (usually "maintenance" changes). The AngularJS Git commit message format is
chore(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
Issues related to continuous integration, delivery, and deployment tasks. The AngularJS Git commit message format is
ci(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
Issues related to continuous integration, delivery, and deployment tasks. The AngularJS Git commit message format is
ci(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
New feature or enhancement requests. The AngularJS Git commit message format is
feat(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
Defect (bug) repair issues. The AngularJS Git commit message format is
fix(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
Performance improvement issues. The AngularJS Git commit message format is
perf(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
Source code design improvements that do not affect product behavior. The AngularJS Git commit message format is
refactor(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
Tasks that revert to a previous commit hash. The AngularJS Git commit message format is
revert(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
Issues related to style guideline compliance, especially ESLint errors and warnings. The AngularJS Git commit message format is
style(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
Test coverage tasks. The AngularJS Git commit message format is
test(<scope>): <subject>
<BLANK LINE>
<[body]>
<BLANK LINE>
<footer>
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.
Write 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.