Max = orange
Related CFitz = Pinkish? Puce?
Sally = Green
Related call notes:
- Re: Separating Prioritization and Testing: Discussion notes
- 2015-12-14 TAC/UAC Coordinating Committee
Implementation notes
Jan 2016 - wrap up of 1.5 release
early Jan tbd - initial early Jan setup meeting of Prioritization Team (may be followed by short weekly check-ins?)
early late Jan - process in place early - mid Jan - schedules and schedules and meeting invitations in place for 2016 releases
late Jan - first Prioritization working meeting (grooming)
Jan 29 - backlog prioritization finished - 1mo worth of stories
sometime in Jan - Testing team meets
Feb 2016 - implement new development process
Feb 1 - Sprint planning meeting
Feb 19 - end of development and concurrent testing
Feb 22 - 26 QA testing
Week of Feb 22 - second Prioritization working meeting (grooming)
Feb 26 - COB ETD end of sprint
Draft Schedule
One release per every four months, three per year
...
Maintenance releases necessary to address critical bugs may occur independent of this schedule.
Draft Process / Cycle
Note - this is a general outline. Further changes and refinements may be made over time as groups are get underway with new cycle and ideas as improvement are raised.
1.Submission
Who: Users
Process step description: Submit a feature request or report a bug in the ArchivesSpace Support JIRA
When: rolling basis
2. Initial evaluation of tickets.
Who: ArchivesSpace Program Team (Brad, Christine, Chris & Brian)
...
It would be good for some group to consider improvements to steps 1 - 3 to in particular bug tracking and reporting as we could probably make some improvements. Currently support requests also come via a number of channels and this causes problem for everyone involved in the process. Need to encourage users to log tickets in support JIRA.
CF: Yes, I agree with the bug reporting. It's compounded by the fact the support JIRA doesn't allow users to follow tickets and that people have to add an email. IMO, the support JIRA hasn't really worked out. Would it be best to just encourage people to record bugs in either 1) Github issues or 2) the mailing list. We add those in JIRA ( since I use completed JIRA tickets to generate the change log )? I think this would eliminate one channel ( the JIRA support ). Users adding their own tickets to the general AR JIRA project often means they just get lost...
Chris - your suggestions sound like good ones that should be discussed / examined further after the new development process is underway. It would be great to have a group (Program Team? one the Documentation sub-teams?) look at the current submission process think through the pros & cons of moving to the 2 alternates you suggest - as well as thinking through any set-up / transition work involved in changing how this is done.
When: rolling basis
3. Move accepted tickets from Support to Dev JIRA.
Who: ArchivesSpace Program Team (Brad, Christine, Chris & Brian)
Process step description: moves sufficiently detailed feature (and non-duplicative) requests and bugs into Development JIRA and categorize with a label, e.g. Epic e.g. 'EAD export'.
When: rolling basis
4. Prioritization / Grooming meeting.
Who: Development Prioritization team
...
When: Before start of each monthly sprint and/or once before start of a 4-month release cycle
5. Sprint Planning meeting.
Here's a draft overview of the meeting I made
Who: Chris Fitzpatrick, Brian Hoffman, Julie Patton Prioritization Group liaison (co-Product Owner?), Brad Westbrook - Product Owner, Testing Lead (and/or individual testers), other contributors, (heads of documentation teams may be interested in joining?)
...
When: Beginning of sprint cycle
6. Development & testing per sprint.
Who: Project Team
Process step description: Project team to work on code and documentation and testers to test functionality as stories are delivered.
...
When: weeks 1 - 3 of each sprint
7. Q/A testing
Who: Program team ( + others?)
...
When: last (4th) week of the sprint
8. Release
Who: Release Manager, Community Support Manager
...
When: three-weeks in advance of the release schedule - release date
Groups involved:
Development Prioritization
Task: On the basis of feature requests and bug reports filed in the development catalog, this team prioritizes development work for each schedule features release (1 per every four months) in advance of the first sprint for each features release.
...
What's in voted queue (early 2016)
Voting for epics (if process is enacted by Prioritization group)
Theme / epic targeted per release
Sufficient specification. (Hydra Project has a good document about what constitutes a well-documented story **Chris F. to share link.** )
Developer responsibility
Anecdotal evidence (listserv discussion, email reports)
Meetings: Monthly (1st month -target features and bugs for release and suggest first sprint; 2nd month - suggest targets for second sprint and groom icebox; 3rd month - suggest targets for third sprint and groom icebox; 4th - start preparation for next sprint)
I changed this from "Agile Team" to "Project team" just because "Agile" feels a bit loaded. Project might be too generic?
Project team (code, testing, and documentation contributors):
Task: Implement features and bug fixes and documentation additions according to prioritization determined by Prioritization team. Will organize prioritized work into three consecutive month-long sprints.
...
for code contributions, unit tests should be included
[Brad to write up notes on overall testing strategy]
Meetings: Sprint planning meetings, 30min standups 3 times / week (M, W, F)
...
Testing:
Task: Testing features and bug fixes, during the first three weeks of a sprint.
...
As a new TAC member who just completed my first testing assignment, I think it would be useful to come up with guidelines on exactly what is expected here, where the outcome should be reported, etc. Maybe this is unique to a particular functionality and gets worked out during the Sprint Planning Meeting?
...
Quality assurance:
Task: Testing features and reviewing prepared documentation during the last week of a sprint to ensure all work necessary for a sprint has been completed or deferred to the following sprint.
...