-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support "break-out" retros #22
Comments
The basics for this are now supported, but there is no UI to discover it (accessible by accessing Remaining work:
The code for managing multiple states has become quite messy (several actions have to be aware of which state they are using). It would be nice to tidy that up, but I don't know how while maintaining an atomic dispatcher (being able to modify items and state simultaneously). |
when groups are "active", the main retro screen should block the ability to add new items (and possibly hide the retro entirely), instead showing links to the current sub-retros (and an option to create a new one). This should aid discoverability for new people joining an existing retro (and will avoid them adding items to the main retro, where behaviour is uncertain) An option could be added to the menu to "activate" sub-retros, then within a sub-retro, an option can be added to return to the main retro (where it is possible to "deactivate" the sub-retros, bringing everybody back to the main retro automatically and returning it to normal functionality) |
For large teams, it can be useful to divide the team into smaller groups for retro facilitation, but it is still useful to store all items and actions in a combined form.
This could be achieved by adding a category to items, and providing filters in the UI. The current
/retros/<id>
path would continue to show all items, with new/retros/<id>/sub/<category>
path which applies the filtering. It may be useful for the main retro to display an indicator (such as a coloured dot) for which sub-retro an item came from (particularly useful when viewing archives).Behind-the-scenes, the full retro state will continue to be shared to all participants, making this a display-level filter. The retro will continue to have a single password which works for the main retro and all sub-retros.
Retro state will also need to be per-category (current data structure location could continue to be used for whole retro, with a dictionary in a new location for sub-retros). Retro settings (e.g. theme) will apply to all sub-retros and does not need any change.
Handling of uncategorised items is to be decided; they could appear on all sub-retros, or could appear only in the main retro. For action items, it seems useful to display all past items in all sub-retros, but perhaps filter new items.
It may be desirable to offer functionality for dividing participants into sub-retros randomly, but this would presumably need some integration with video conferencing break-out rooms. Pulling all sub-retros back to the main retro may also be desirable (i.e. pushing a redirect to all participants). Both of these features should be split out as separate work.
Archiving will continue to apply to the whole retro.
The text was updated successfully, but these errors were encountered: