-
Notifications
You must be signed in to change notification settings - Fork 195
Issue triage, communication, and delivery
The project is supported primarily by Garth and Bernhard, with Garth acting as lead. 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 work needed to get RSP v3 delivered, 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 will no longer support IE11 in the new versions of spectrum-css. We can accept patches to a branch where IE11 is supported as time permits. Those requiring IE11 sooner 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 will be made available via github, and the plan for broader efforts (eg. RSP v3) will be documented as well. 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 when 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.
For tracking reasons, some of the issues here are replicated in Jira (internal to Adobe). The issues here in github are seen as the master, which means if there's a discrepancy, refer to github for the correct information.
This repo's projects functionality will be used for backlog grooming, sprint planning, and tracking issue status.
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 same day completion of a review as a general goal. 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 "Work in Progress". 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.
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