Subject: [TOOLS-DEVELOPMENT] Outline of tasks for improving the meeting scheduling tool.

From: Robert Sparks <[email-masked]>
Date: Wed, 24 Oct 2018 11:06:36 -0500

All -

Below is an outline of the things that need to improve with the meeting 
scheduling tool. Please skim and let me know if there are any big items 
that you think are missing. Please comment where I call out open 
questions. The primary TODO below is to identify and name the types of 
things we are currently lumping in as "non-session sessions". I hope to 
use a few brainstorming sessions in Bangkok to build that set of things. 
This is not, of course, in the form we would use for an SoW - prose 
needs to be created. But before building that, I want to make sure we're 
targeting the right things.

----

- Improve scheduling working/research group sessions
     - Working with an individual schedule
         - Use bootstrap to display the agenda edit page
             - Remove the broken “show/hide” navigation mechanic (see 
the [>] button in the upper left).
             - Reduce the real-estate taken by the “You must save” and 
“Save as” dialogs (#1429)
             - Open Question: Remove the ability to slide days around? 
The secretariat is not using it.
             - Consider removing the ability to hide a room or a day 
(and the [show all] button with it. The secretariat is not using it.
             - Rendered HTML is currently invalid - result should pass 
HTML validator checks.
             - Javascript is currently putting a lot of debugging 
information on the browser console
                 - Logging should either be removed or make the log 
levels selectable
         - Restructure the communication with between the browser and 
the server to be more efficient.
             - The current implementation makes several hundred requests 
for information about individual sessions, groups, their needed 
resources, and their conflicts. A single combined request would be more 
efficient.
         - Make it easier to see AD conflicts on the grid - the 
secretariat has to do this manually right now.
         - Must-be-present doesn’t show on the grid at all. The 
secretariat feels the data is not well groomed enough for it to be 
useful if it showed (there is concern about knot knowing who these 
people are well enough to make judgement calls on whether the declared 
conflict is really reasonable).
         - Make it possible to swap two entire columns on the drag-drop 
view (e.g. switch Wed and Tue morning). The secretariat does this 
frequently while building a schedule, sometimes while on the 
conflict-resolution call. It currently requires many drag-drop options 
to the unscheduled field, and is error prone.
         - Make groups that are in slots that don’t match their 
requested time more visually distinct (#1428)
         - Greying out sessions by area should work whether you own an 
agenda or not (#1584)
         - If a session is moved after the agenda is finalized, the 
agenda view should show something in the old time slot pointing to the 
new time slot.
             - Add a SessionStatusName of ‘rescheduled’. When a session 
is moved after the agenda is finalized, create a new session with the 
original SchedTimeSessAssignment, and place it in status 'rescheduled'.
             - Open Question: Is this WG/RG session specific? Should 
this happen to private meetings that are rescheduled?
     - Working with the set of schedules
         - Add a way to track changes to a schedule. Needs to be easier 
to remember what’s different between two versions
             - The typical workflow is to copy a schedule and make a few 
changes
             - Add a history that captures changes to a given schedule.
                 - If this uses events, it will be different from 
SchedulingEvents. These need to be aware of changes to 
SchedTimeSessAssignment for a given schedule.
             - Open Question: Should we provide a diff between two 
schedules?
         - Add notes describing a version.
             - The name field isn’t big enough to be descriptive, and it 
is created before the description is really known.
             - Saving a new copy with a shorter descriptive name just 
makes clutter.
         - Page at /meeting/103/agendas/list can be made more useful
             - Consider grouping by (visible, public)
             - The Edit button does not take the user to a place to edit 
the schedule - the resulting form is for changing the name of the 
schedule, deleting it, making it official, or changing it’s (visible, 
public) status. The presentation should be more self-documenting.
             - The notes describing versions should be available here 
(at least in summary). These notes should be searchable.
- Improve setting up a new meeting
     - Setting up a new meeting is currently inefficient - normally 
repeating things are scheduled on the wrong day (probably a bug 
introduced when we started starting meetings on Saturday). Copying 
things forward from previous meetings is not working as expected. 
Currently the secretariat has to do a lot of deletes/adds when setting 
up the new schedule.
     - The current workflow is to add things that should be the same 
across all agendas (like breaks and registrations sessions) to the 
“Empty” agenda. Concrete proposed schedules start by making a copy of 
the “Empty” agenda. Unfortunately, if the breaks or registration 
sessions need to change after some concrete schedules have been started, 
those changes have to be manually made to each copy.
     - Create a base schedule that all schedules inherit from
         -  Things like breaks and registration would live in the base 
schedule
         - Changes to this base schedule would affect all schedules 
immediately.
         - Make sessions from the base schedule visually distinct 
wherever such sessions are shown graphically, such as /meeting/103/room-view
- Improve the ability to schedule meetings that are not WG meetings
     - The non-session concept is overused, and talking about 
non-session sessions is counterintuitive. A redesign of the objects to 
give the non-session things usefully conceptual names is needed. Views 
that talk about “non-session” need to be updated to speak in terms of 
what they are actually working with.
         - Some of these things have materials, like ANRW and hotrfc
         - TODO: Describe each of the things and give them names
     - Improve the flexibility of the grid
         - Allow rooms to have different grids
         - It’s currently expected that WG/RG session rooms would all 
share the same grid, and sessions of other types would be scheduled in 
rooms with a different grid. Thus, the drag-drop views don’t need to 
support mixed grids at the moment, but care should be taken with the 
code anticipating that we would need to support them in the future.
         - /meeting/timeslots/edit, in particular, will need adjustment 
to handle rooms having different grids.
             - Possibly group rooms that share a common grid structure.
     - Make it easy to control what types of sessions do and dont appear 
on the official agenda page.
     - Allow graphical scheduling of non-wg sessions
         - Open Question: Choose between these options
         - Option 1
             - Create a separate page similar to the WG/RG drag and drop.
         - Option 2
             - Allow graphical scheduling and rescheduling of non rg/wg 
sessions directly on /meeting/room-view
             - Consider helper links from /by-type and /by-room to 
assist with finding and moving sessions.
     - Consider adding views that show “Isoc meetings” or “Private 
meetings” where we have room-view etc now, or perhaps leverage the 
customized agenda view - letting the secretariat select whether they see 
things on that view.
- Improve session request handling
     - There were three groups at 103 that listed themselves as first 
order conflicts. The form needs stricter validation.
         - Groups can’t list themselves as conflicts
         - Closed WGs or Bofs can’t be listed as conflicts
     - Lots of requests list groups that are closed, or bofs that have 
passed.
     - The secretariat expresses concern about the quality of the group 
conflict data and the must-be-present data. Should we change the tooling 
to make it more likely the lists get maintained? (The IESG would need to 
make this decision).
- Improve meeting statistics
     - There is currently a manually created report for the IESG that 
summarizes the number of sessions requested per area, and the number of 
requests of each length (per area). This can be automated.
     - Add a view reachable from the session-request pages (e.g. 
meeting/requests) that produces that summary.
     - Add graphs. Allow showing one meeting or a comparison against 
recent/all meetings.
     - Allow the user to view the reports/graphs showing what was 
“requested” and what “actually met”.
- Improve testing
     - All the javascript needs automated testing
- Improve the community’s view of the agenda
     - Modify the week-view in the agenda to allow selection/deselection 
of the ‘non-wg’ events (codesprint, systers lunch, etc).
     - Modify the week-view custom urls to use a query string rather 
than a fragment list. (Apps use fragments for other things too). 
Calendar subscriptions should still work. Consider having a browser 
cookie available to store preferences between meetings (see #1991)
     - Add an “All Bofs” customization button (#2314). Consider also an 
“All newcomers” or “running code” groups.
     - Add an important date ics feed.  There is a manually created 
important dates calendar on the ietf website currently.
         - Possibly include important dates in the upcoming meeting 
calendar.
     - Reduce the granularity of IETF meetings in the “Upcoming 
meetings” ics.
         - Possibly allow selectors to only show IETF meetings where 
group “foo” has a session
         - See #2605 and #2216
- Improve materials handling for interims
     - Allow uploading of recordings for interims (#2471, #2467)
- Code-base cleanup
     - Code has a mix of “schedule” and “agenda” in it. Picking one and 
converting would be better.
     - A session object currently has a ‘scheduled’ datetime attribute 
that records the time that the object first enters the ‘sched’ state. 
This should be replaced with a relation to a new event class: 
SchedulingEvent, that records all status transitions.
- New Bugs
     - Inactive address chosen when saving an agenda - 2611
     - When creating non-session items, setting location often doesn’t 
stick. Sometimes it takes multiple saves to get it to work.
     - Groups populate incorrectly on an empty schedule - the 
non-session screen display is broken. Stephanie will show Ryan and 
develop a more detailed report.

---

From: Russ Housley <[email-masked]>
Date: Thu, 25 Oct 2018 14:25:34 -0400

We used to have the concept of a meeting template.  Templates had names.  In this write-up, you talk about a "base schedule".  I cannot tell if they are the same.

Russ

> On Oct 24, 2018, at 12:06 PM, Robert Sparks <[email-masked]> wrote:
> 
> All -
> 
> Below is an outline of the things that need to improve with the meeting scheduling tool. Please skim and let me know if there are any big items that you think are missing. Please comment where I call out open questions. The primary TODO below is to identify and name the types of things we are currently lumping in as "non-session sessions". I hope to use a few brainstorming sessions in Bangkok to build that set of things. This is not, of course, in the form we would use for an SoW - prose needs to be created. But before building that, I want to make sure we're targeting the right things.
> 
> ----
> 
> 
>            - Remove the broken “show/hide” navigation mechanic (see the [>] button in the upper left).
>            - Reduce the real-estate taken by the “You must save” and “Save as” dialogs (#1429)
>            - Open Question: Remove the ability to slide days around? The secretariat is not using it.
>            - Consider removing the ability to hide a room or a day (and the [show all] button with it. The secretariat is not using it.
>            - Rendered HTML is currently invalid - result should pass HTML validator checks.
>            - Javascript is currently putting a lot of debugging information on the browser console
>                - Logging should either be removed or make the log levels selectable
>        - Restructure the communication with between the browser and the server to be more efficient.
>            - The current implementation makes several hundred requests for information about individual sessions, groups, their needed resources, and their conflicts. A single combined request would be more efficient.
>        - Make it easier to see AD conflicts on the grid - the secretariat has to do this manually right now.
>        - Must-be-present doesn’t show on the grid at all. The secretariat feels the data is not well groomed enough for it to be useful if it showed (there is concern about knot knowing who these people are well enough to make judgement calls on whether the declared conflict is really reasonable).
>        - Make it possible to swap two entire columns on the drag-drop view (e.g. switch Wed and Tue morning). The secretariat does this frequently while building a schedule, sometimes while on the conflict-resolution call. It currently requires many drag-drop options to the unscheduled field, and is error prone.
>        - Make groups that are in slots that don’t match their requested time more visually distinct (#1428)
>        - Greying out sessions by area should work whether you own an agenda or not (#1584)
>        - If a session is moved after the agenda is finalized, the agenda view should show something in the old time slot pointing to the new time slot.
>            - Add a SessionStatusName of ‘rescheduled’. When a session is moved after the agenda is finalized, create a new session with the original SchedTimeSessAssignment, and place it in status 'rescheduled'.
>            - Open Question: Is this WG/RG session specific? Should this happen to private meetings that are rescheduled?
>        - Add a way to track changes to a schedule. Needs to be easier to remember what’s different between two versions
>            - The typical workflow is to copy a schedule and make a few changes
>                - If this uses events, it will be different from SchedulingEvents. These need to be aware of changes to SchedTimeSessAssignment for a given schedule.
>            - Open Question: Should we provide a diff between two schedules?
>            - The name field isn’t big enough to be descriptive, and it is created before the description is really known.
>            - Saving a new copy with a shorter descriptive name just makes clutter.
>            - The Edit button does not take the user to a place to edit the schedule - the resulting form is for changing the name of the schedule, deleting it, making it official, or changing it’s (visible, public) status. The presentation should be more self-documenting.
>            - The notes describing versions should be available here (at least in summary). These notes should be searchable.
>    - Setting up a new meeting is currently inefficient - normally repeating things are scheduled on the wrong day (probably a bug introduced when we started starting meetings on Saturday). Copying things forward from previous meetings is not working as expected. Currently the secretariat has to do a lot of deletes/adds when setting up the new schedule.
>    - The current workflow is to add things that should be the same across all agendas (like breaks and registrations sessions) to the “Empty” agenda. Concrete proposed schedules start by making a copy of the “Empty” agenda. Unfortunately, if the breaks or registration sessions need to change after some concrete schedules have been started, those changes have to be manually made to each copy.
>        -  Things like breaks and registration would live in the base schedule
>        - Changes to this base schedule would affect all schedules immediately.
>        - Make sessions from the base schedule visually distinct wherever such sessions are shown graphically, such as /meeting/103/room-view
>    - The non-session concept is overused, and talking about non-session sessions is counterintuitive. A redesign of the objects to give the non-session things usefully conceptual names is needed. Views that talk about “non-session” need to be updated to speak in terms of what they are actually working with.
>        - It’s currently expected that WG/RG session rooms would all share the same grid, and sessions of other types would be scheduled in rooms with a different grid. Thus, the drag-drop views don’t need to support mixed grids at the moment, but care should be taken with the code anticipating that we would need to support them in the future.
>        - /meeting/timeslots/edit, in particular, will need adjustment to handle rooms having different grids.
>    - Make it easy to control what types of sessions do and dont appear on the official agenda page.
>            - Allow graphical scheduling and rescheduling of non rg/wg sessions directly on /meeting/room-view
>            - Consider helper links from /by-type and /by-room to assist with finding and moving sessions.
>    - Consider adding views that show “Isoc meetings” or “Private meetings” where we have room-view etc now, or perhaps leverage the customized agenda view - letting the secretariat select whether they see things on that view.
>    - There were three groups at 103 that listed themselves as first order conflicts. The form needs stricter validation.
>    - Lots of requests list groups that are closed, or bofs that have passed.
>    - The secretariat expresses concern about the quality of the group conflict data and the must-be-present data. Should we change the tooling to make it more likely the lists get maintained? (The IESG would need to make this decision).
>    - There is currently a manually created report for the IESG that summarizes the number of sessions requested per area, and the number of requests of each length (per area). This can be automated.
>    - Add a view reachable from the session-request pages (e.g. meeting/requests) that produces that summary.
>    - Add graphs. Allow showing one meeting or a comparison against recent/all meetings.
>    - Allow the user to view the reports/graphs showing what was “requested” and what “actually met”.
> - Improve testing
>    - Modify the week-view in the agenda to allow selection/deselection of the ‘non-wg’ events (codesprint, systers lunch, etc).
>    - Modify the week-view custom urls to use a query string rather than a fragment list. (Apps use fragments for other things too). Calendar subscriptions should still work. Consider having a browser cookie available to store preferences between meetings (see #1991)
>    - Add an “All Bofs” customization button (#2314). Consider also an “All newcomers” or “running code” groups.
>    - Add an important date ics feed.  There is a manually created important dates calendar on the ietf website currently.
>        - Possibly include important dates in the upcoming meeting calendar.
>    - Reduce the granularity of IETF meetings in the “Upcoming meetings” ics.
>        - Possibly allow selectors to only show IETF meetings where group “foo” has a session
>        - See #2605 and #2216
>    - Code has a mix of “schedule” and “agenda” in it. Picking one and converting would be better.
>    - A session object currently has a ‘scheduled’ datetime attribute that records the time that the object first enters the ‘sched’ state. This should be replaced with a relation to a new event class: SchedulingEvent, that records all status transitions.
> - New Bugs
>    - When creating non-session items, setting location often doesn’t stick. Sometimes it takes multiple saves to get it to work.
>    - Groups populate incorrectly on an empty schedule - the non-session screen display is broken. Stephanie will show Ryan and develop a more detailed report.
> 
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Oct 2018 13:33:54 -0500

> We used to have the concept of a meeting template.  Templates had names.  In this write-up, you talk about a "base schedule".  I cannot tell if they are the same.
Can you say more? I don't believe the datatracker has ever had a formal 
template concept. When a new meeting is created an "Empty" schedule is 
built. That can be edited to have things like breaks in it, and then 
that can be copied to build a particular proposed agenda in. Are you 
remembering something else?

The "base schedule" concept I talk about below is new, and doesn't 
currently exist in the code. The fundamental idea here is that any 
changes to that base schedule would be inherited (appear immediately) by 
all other schedules for that meeting.

---

From: Russ Housley <[email-masked]>
Date: Thu, 25 Oct 2018 15:36:00 -0400

> On Oct 25, 2018, at 2:33 PM, Robert Sparks <[email-masked]> wrote:
> 
> Can you say more? I don't believe the datatracker has ever had a formal template concept. When a new meeting is created an "Empty" schedule is built. That can be edited to have things like breaks in it, and then that can be copied to build a particular proposed agenda in. Are you remembering something else?

See https://iaoc.ietf.org/documents/Agenda-Scheduling-Tool-RFP-2012-05-24-Final.pdf.  It talks about meeting agenda templates.

> The "base schedule" concept I talk about below is new, and doesn't currently exist in the code. The fundamental idea here is that any changes to that base schedule would be inherited (appear immediately) by all other schedules for that meeting.

I think this is what was envisioned by meeting agenda templates.  The grid comes from the template, but different WG/RG assignments to the slots will be made for a meeting that uses a particular template.

Russ

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Oct 2018 14:42:59 -0500

> I think this is what was envisioned by meeting agenda templates.  The grid comes from the template, but different WG/RG assignments to the slots will be made for a meeting that uses a particular te…
So, I think you are agreeing with what the outline proposes this project 
should do. Am I missing anything?

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Oct 2018 14:48:17 -0500

And to be complete

> See https://iaoc.ietf.org/documents/Agenda-Scheduling-Tool-RFP-2012-05-24-Final.pdf.  It talks about meeting agenda templates.
And this was realized in code as I describe. The notion of template is 
the collection TimeSlot objects for the meeting, and is made available 
through the default "Empty" schedule that can be copied.

---

From: Russ Housley <[email-masked]>
Date: Thu, 25 Oct 2018 16:48:59 -0400

> On Oct 25, 2018, at 3:42 PM, Robert Sparks <[email-masked]> wrote:
> 
> So, I think you are agreeing with what the outline proposes this project should do. Am I missing anything?

No.  I am just advocating consistent terminology.

Russ

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Oct 2018 16:31:51 -0500

> No.  I am just advocating consistent terminology.
I agree.
There are also lots of other places in the meeting code we should put 
this pressure on.