-
Notifications
You must be signed in to change notification settings - Fork 195
Issue triage, communication, and delivery
The project is supported primarily by @pfulton (lead) and @castastrophe. Other S.E. team members will contribute from time to time. The community (both inside and outside of Adobe) may also contribute.
While our primary focus in the near term is the migration of components to the new token library, we must also keep spectrum-css platform agnostic. We will continue to be responsive to the needs of the other frameworks in use at Adobe.
We do not support IE11. We can accept patches to a branch where IE11 is supported as time permits. Those requiring IE11 are welcome to maintain that branch as well.
There is some ongoing need to bug fix the older versions of css that are used by V2 of RSP. We can address those issues as second priority, and accept patches from teams who are still using V2 components. This will be done on a branch.
At a minimum, a member of the Spectrum Engineering team will respond to issues via a comment within one business day of the issue being file. Sprint plans exist within Adobe's internal Jira instance and issues opened in GitHub are synced and tracked against their peer in Jira. A detailed listing of priority per each issue isn't feasible, but more detail per issue can be provided as needed.
There is an issue template in the .github folder of the project; please use that for filing issues. Tagging will be handled by the S.E. team, though you're welcome to have a go at it when you create the issue. Don't take it personally if some tidying up happens along the way.
Pull requests must be reviewed before being merged. Review should involve at least one peer from the S.E. team, nominated as reviewer. That reviewer will help facilitate an efficient turn around for feedback and merging, with a one-week completion of a review as a general goal (shorter for smaller pull requests). We will also strive to use conversation comments to make it clear what action is pending and when a resolution is expected. In-person or Slack discussion will be reflected back into the comments as needed.
If a pull request is started, but not ready for review, it will be marked as draft. In that state, a more relaxed communication on status is allowed, but clear expectations should still be a goal.
In the case of difficulty resolving decisions or difference of opinion, please note that project leadership or Spectrum management will facilitate and optionally end discussion at their discretion.
Note: the 1st and 7th places are prompts for reasoning about work, not actually used.
Correlated with the sizing labels.
| Size | Points | Description | Days-ish | Hours-ish |
|---|---|---|---|---|
| Trival | < 1 | So quick and easy we should not bother tracking the effort | -- | -- |
| Extra Small (XS) | 1 | Nearly trivial, a few hours, could do more than one in a single day | < 1 day | 1 - 6 |
| Small (S) | 2 | Not hard or time consuming, one or two work days to complete | 1 - 3 days | 6 - 18 |
| Medium (M) | 3 | Moderate effort or complexity, several work days needed | 3 - 5 days | 18 - 30 |
| Large (L) | 5 | Lots of effort or complexity, most of a sprint needed to complete | 5 - 7 | 30 - 42 |
| Extra Large (XL) | 8 | Huge effort, high complexity, takes a whole sprint, maybe break down | 7 - 9 | 48 - 54 |
| Epic | > 8 | Too big for a single sprint, find a way to break this work into parts | -- | -- |
The idea of ‘Days-ish’ and ‘Hours-ish’ are used because time is unpredictable. The ‘ish’ reminds us estimates are a discussion point only; time in this exercise is used simply to assist in reasoning about scope. The ‘ish’ values cannot be used as a literal or for any sort of math.
Detailed description of other labels
-
a11y: anything the accessibility folks would want to know about -
beta design: already tracked as a contribution -
breaking change: flags issues as more serious -
blocked: if this issue cannot move forward due to a dependency -
blocks: places where we are blocking someone else -
breaking change: this will break something -
bug: places where Spectrum-CSS is wrong -
decruft: issue that needs to be cleaned up -
design change: a way to separate that from housekeeping -
documentation: not housekeeping or adesign change -
duplicate: represents issues already reported, should be closed -
i18n: Things like[dir]and other i18n related work -
icebox: stuff we will probably never get around to doing; archived -
new component: a component that is requested or under development -
prototype: added by jiratron to track work design needs -
question: used by outside people to communicate with our team -
research: flags research needed or in progress -
wontfix: rejected issues
Comments in issues and pull requests will be our main method of communication outside of Adobe. A general expectation of responding to things in a reasonable amount of time will be followed. Note we measure reasonable in hours, not minutes.
Internally, we will respond to Slack promptly, again using the general rule of responding in a reasonable amount of time, measured in hours, not minutes. If more than a business day goes by, please escalate as needed.
For the latest (and obviously greatest) work, we commit to one release per sprint. We may release interim patches as needed.
For other branches (eg. RSP v2, IE11 support, etc), we will release as necessary, allowing for the fact that our main focus should take priority over supporting branches.
It should be noted that we have a code of conduct for a reason. If it is not being followed, please let us know, so we can resolve and concerns immediately.
We will request design review for any pull request as needed. A comment reflecting that process, and the result, will be added to the PR conversation.
For review that takes place outside of that process, Design will notify us of changes they know are needed via issues in github. This is generally handled by auto-generated issues in Jira, which will get mirrored here to keep this resource the master.
Currently this is handled when RSP gets reviewed. We are looking into adding that into our own process directly and will document the outcome of that once there's a plan