Content
View differences
Updated by Parimal Satyal almost 3 years ago
**As** a project members
**I want to** build meeting agendas, add invitees and document important information and decisions
**so that** our meetings are more efficient and key information is documented and easy to find.
### Note
These define the functional scope (the what) of the feature and do not yet go into the specifics of _how_ different parts will be implemented. Once this feature is set to specified, UX and Front-end will co-create the UI/UX of the feature using existing Primer ViewComponents as much as possible.
### Acceptance criteria
A new Meetings module (based on Primer) will replace the existing one:
* A meeting consists of meeting details, agenda items and invitees.
* **Meeting details are:**
* Title of the meeting (required)
* _Mode Mode (see below, required)_ required)
* Date (required)
* Time (eg. 1 PM – 3 PM, optional)
* Duration (manually set) ~~or set or derived from the agenda items)~~ time field)
* Duration is marked in red if the set duration is longer than the sum of the duration of agenda items
* Place or Link (optional)
* **Invitees** can have one of three roles (note: link with Klaus' work on roles/permissions)
* two roles: moderator (no limitation on #)
* author is by default a moderator
* optionally, any participant designated as such
* participant
* invitees
* viewer: everyone or participant. Everyone else in the project who is not a moderator or participant is a viewer.
* A meeting can be in one of four statuses:
* **Draft agenda** (default for new meetings):
* Moderators can edit and modify meetings details, add invitees and construct the meeting agenda by adding agenda items. They can also rearrange agenda items by dragging them up or down.
* Participants can only add or modify their own agenda items.
* Viewers (non invitees) cannot see the meeting yet (?)
* **Finalised agenda**: a moderator sets the mode to finalised to lock the agenda before a meeting.
* Moderators can change state to draft to change the actual agenda; participants cannot do this.
* Moderators can change meeting details (name, time, date...) and add/remove invitees.
* Participants can add (but not remove?) invitees.
* Viewers can now view the meeting in read-only mode.
* **Meeting in Progress**: a moderator sets the mode to In Progress when the meeting actually takes place.
* Moderators can once again modify agenda items own items and add/remove additional items to agenda items (clarificatoin need or decision).
* Participants can only modify or add/remove additional items to their _own_ items.
* Viewers can view only.
* **Meeting closed**
* Read-only for everyone but
* Moderators can change status to any of the above
* **Sections (optional)** **Sections**
* _Note: add technical complexity, but complex meetings would benefit from them._
* Group of agenda items
* ~~\[open\] \[open\] Responsible? Title\* Duration?~~ Duration?
* **Agenda items:**
* Meetings consist of agenda items.
* At their most basic, agenda items have:
* Title (required)
* Responsible (optional)
* Just a user object that's displayed; no functional implication
* _Just one ~~multiple?~~_
* ~~Required participants for this agenda item~~
* Duration (optional)
* Integer field, in minutes
* _Risk: if some agenda items have duration Moderators and others don't; the total duration will be misleading since some items will have a duration of zero_
* Description: Participants may add additional elements:
* Text area: CKEditor Additional information (text area)
* _restrictive? _OG: Maybe restricted CKEditor, with basic bold, italic, maybe links... maybe no tables links?_
* Open point (text field; this can be a open point or images?_ a decision once resolved)
* The meeting title can also be replaced with a work package:
* By default, Typing "#" on the type is "Title" but the user can alternatively select other types with a drop down:
* Title
* Work package
* Turns the input field title turns it into a search bar, and typing keywords displays results in a drop modal.
* \[open\] There's perhaps a visual way of doing this (a dropdown?).
* The user can select the corresponding work package.
* _\[open\] Power user: Typing "#" in the title field selects work package._
* _\[open\] OG: Work package search thing we have is Angular, we have to see how to make it work with Primer._
* The title is now replaced with the work package details (id, Subject, type, status)
status).
* _\[open\] Clicking on the work package title opens it in a new tab.
* _~~\[open\] Clicking on the work package opens the work package in a split screen.~~_
screen._
* _~~In To go back to title, the short term, would require having Angular code.~~_
* _~~In the long term, Primer offers overlays that slide in from the right side that we could potentially use for this.~~_
* Users should be able user has to "remove" remove the work package by selecting a basic title field instead in Edit mode.
package.
* The title is empty (to make it absolutely clear that there's no connection to the WP).
* Functionally, other Other agenda elements (duration, responsible, description) additional information, decision) are unrelated to the work package and do not affect it.
package.
* Open points are the only exception, _\[open\] OG: Work package search thing we have is Angular, we have to see ###49578 how to make it work with Primer._
* Agenda items have two states, display and edit:
* In display state, agenda details cannot be edited but moderators can drag them up and down to to change the order (mode allowing).
* In edit state, these fields are visible:
* Title (text field, typing # turns it into a search field)
* Duration in minutes (integer)
* Responsible (user search)
* Buttons to add an open point, and a remove button once each is added:
* This can be an "Open point" or a "Decision" once it is resolved
* Save button.
* Agenda items have hover actions, depending on status:
* Drag
* Edit
* Mor
* **Mobile**: Viewing meetings is a priority.
* **Notifications:** **Notifications:**
* Create an open point related to a work package.
* Out of scope:
* Invited to a meeting
* Meeting modified
* Meeting status changed
* Meeting rescheduled
* _Note: right now Notifs limited to work packages (so possible to show meetings objects linked to WPs)_
### Open
* Journalising/see history of edits of minutes?
* What if the work package is included as an agenda item in a meeting but without any decision need/clarification? Where would the meeting be visible in the work package view?
* How should we handle migration and old meetings?
* ~~We lose iCal integration?~~
* Idea: Decision and issues log?
* Ways to be able to show relevant meetings from work packages.
* Later, possible to show and filter through decisions/clarification needs?
### Out of scope
This first version of the new Meetings module for version 13.1 will not include:
* The ability to add clarification needs and decisions are specified in a separate feature:
* ###49578
* Additional elements attached to agenda items:
* Notes
* Commenting and emoji reactions
* Comment threads
* Agenda backlog (a set of agenda items that are "parked" and do not show up in the actual meeting, simliar to drafts)
* Send existing agenda item to backlog
* Send backlog item to agenda
* Move existing agenda item to another meeting
* Meeting series (recurring)
* Web conference tool
* ~~iCal integration~~
### Mockup
**Important:** Final mockups will be co-designed with front-end devs using Primer View components once the scope is finalised.
For reference, see existing test Figma mockups: https://www.figma.com/file/4pe9naCoEzlnbco9Ynl9k9/Automatic-Meeting-Agenda?type=design&node-id=1020-21095&mode=design
**I want to** build meeting agendas, add invitees and document important information and decisions
**so that** our meetings are more efficient and key information is documented and easy to find.
### Note
These define the functional scope (the what) of the feature and do not yet go into the specifics of _how_ different parts will be implemented. Once this feature is set to specified, UX and Front-end will co-create the UI/UX of the feature using existing Primer ViewComponents as much as possible.
### Acceptance criteria
A new Meetings module (based on Primer) will replace the existing one:
* A meeting consists of meeting details, agenda items and invitees.
* **Meeting details are:**
* Title of the meeting (required)
* _Mode
* Date (required)
* Time (eg. 1 PM – 3 PM, optional)
* Duration (manually set) ~~or
* Duration is marked in red if the set duration is longer than the sum of the duration of agenda items
* Place or Link (optional)
* **Invitees** can have one of three roles (note: link with Klaus' work on roles/permissions)
*
* author is by default a moderator
* optionally, any participant designated as such
* participant
* invitees
* viewer: everyone
* A meeting can be in one of four statuses:
* **Draft agenda** (default for new meetings):
* Moderators can edit and modify meetings details, add invitees and construct the meeting agenda by adding agenda items. They can also rearrange agenda items by dragging them up or down.
* Participants can only add or modify their own agenda items.
* Viewers (non invitees) cannot see the meeting yet (?)
* **Finalised agenda**: a moderator sets the mode to finalised to lock the agenda before a meeting.
* Moderators can change state to draft to change the actual agenda; participants cannot do this.
* Moderators can change meeting details (name, time, date...) and add/remove invitees.
* Participants can add (but not remove?) invitees.
* Viewers can now view the meeting in read-only mode.
* **Meeting in Progress**: a moderator sets the mode to In Progress when the meeting actually takes place.
* Moderators can once again modify agenda items own items and add/remove additional items to agenda items (clarificatoin need or decision).
* Participants can only modify or add/remove additional items to their _own_ items.
* Viewers can view only.
* **Meeting closed**
* Read-only for everyone but
* Moderators can change status to any of the above
* **Sections (optional)**
* _Note: add technical complexity, but complex meetings would benefit from them._
* Group of agenda items
* ~~\[open\]
* **Agenda items:**
* Meetings consist of agenda items.
* At their most basic, agenda items have:
* Title (required)
* Responsible (optional)
* Just a user object that's displayed; no functional implication
* _Just one ~~multiple?~~_
* ~~Required participants for this agenda item~~
* Duration (optional)
* _Risk: if some agenda items have duration
* Description:
* Text area: CKEditor
* _restrictive?
* Open point (text field; this can be a open point
* The meeting title can also be replaced with a work package:
* By default,
* Title
* Work package
* Turns the input field
*
* _\[open\] Power user: Typing "#" in the title field selects work package._
* _\[open\] OG: Work package search thing we have is Angular, we have to see how to make it work with Primer._
* _~~\[open\] Clicking on the work package opens the work package in a split screen.~~_
* _~~In the long term, Primer offers overlays that slide in from the right side that we could potentially use for this.~~_
* Users should be able
* Functionally, other
* Agenda items have two states, display and edit:
* In display state, agenda details cannot be edited but moderators can drag them up and down to to change the order (mode allowing).
* In edit state, these fields are visible:
* Title (text field, typing # turns it into a search field)
* Duration in minutes (integer)
* Responsible (user search)
* Buttons to add an open point, and a remove button once each is added:
* This can be an "Open point" or a "Decision" once it is resolved
* Save button.
* Agenda items have hover actions, depending on status:
* Drag
* Edit
* Mor
* **Mobile**: Viewing meetings is a priority.
* **Notifications:**
* Create an open point related to a work package.
* Out of scope:
* Invited to a meeting
* Meeting modified
* Meeting status changed
* Meeting rescheduled
* _Note: right now Notifs limited to work packages (so possible to show meetings objects linked to WPs)_
### Open
* Journalising/see history of edits of minutes?
* What if the work package is included as an agenda item in a meeting but without any decision need/clarification? Where would the meeting be visible in the work package view?
* How should we handle migration and old meetings?
* ~~We lose iCal integration?~~
* Idea: Decision and issues log?
* Ways to be able to show relevant meetings from work packages.
* Later, possible to show and filter through decisions/clarification needs?
### Out of scope
This first version of the new Meetings module for version 13.1 will not include:
* The ability to add clarification needs and decisions are specified in a separate feature:
* ###49578
* Additional elements attached to agenda items:
* Notes
* Commenting and emoji reactions
* Comment threads
* Agenda backlog (a set of agenda items that are "parked" and do not show up in the actual meeting, simliar to drafts)
* Send existing agenda item to backlog
* Send backlog item to agenda
* Move existing agenda item to another meeting
* Meeting series (recurring)
* Web conference tool
* ~~iCal integration~~
### Mockup
**Important:** Final mockups will be co-designed with front-end devs using Primer View components once the scope is finalised.
For reference, see existing test Figma mockups: https://www.figma.com/file/4pe9naCoEzlnbco9Ynl9k9/Automatic-Meeting-Agenda?type=design&node-id=1020-21095&mode=design