Document how to edit an issue

[ianbjacobs]

Proposal:

• Upon issue creation, inject a comment into the discussion thread that thanks the creator of the issue and links to documentation about issue edits before and after TPAC.
• We would create documentation that describes both how the meeting managers may edit the issue and how the session chair can edit the issue to modify the description, add links to agenda and materials, and then to minutes. The managers will also, e.g., add links to recordings.

[ianbjacobs]

Proposal:

• Drop the Materials section (but add Agenda section per issue Drop Agenda link? #53).
• After the meeting, generate a Meeting Record section with space for links to minutes, slides, and recordings. Include a link inline to documentation about how to edit this section.

[ianbjacobs]

Updated "how to update a session:
https://github.com/w3c/tpac-breakouts/wiki/Good-Practices-for-Session-Chairs#how-to-update-a-session

This includes a link that can be used when the "Meeting Record" section of the issue is added:
https://github.com/w3c/tpac-breakouts/wiki/Good-Practices-for-Session-Chairs#add-meeting-record-information-after-the-breakout

[tidoust]

One thing I had overlooked is that we need to store the link to the calendar entry in that "Meeting Record" section (useful for people but also for tooling so that it can tell which entry to update) as soon as that calendar entry gets created, meaning before the meeting.

[ianbjacobs]

What if we move things around a bit and create a new Attend this Session
section that has the following information:

• Who can attend
• Link to calendar entry
• Info about IRC

(and anything else related to attendance).

[tidoust]

So far, the sections remain directly linked to the form we use to propose a session. Through that form, we cannot ask about two pieces of information (who can attend and what IRC channel to use) and then hope that GitHub will restructure the responses as a list into a single "Attend this Session" section.

Now, we already run updates on the issue description and re-serialize it, so it's totally possible to have a job that runs when a user creates an issue and reformats the description according to a new structure. A bit painful though (code needs to understand two structures instead of one).

[ianbjacobs]

Through that form, we cannot ask about two pieces of information (who can attend and what IRC channel to use) and then hope that GitHub will restructure the responses as a list into a single "Attend this Session" section.

I had hoped it would be possible to get subsections in YAML. I infer from your comment that won't work. And I see from the syntax description that markdown is not submitted.

[ianbjacobs]

I've updated the documentation based on our discussion today. I now anticipate there will be two injected sections:

• One for the calendar (to be created as soon as the session has been scheduled)
• One for "Meeting Materials" (to be created around the time of the meeting or shortly afterwards).

In addition, we did the following:

• Tweak the template to add a "Logistics" section for IRC.

[tidoust]

OK, code should now be aligned with the documentation. The link to the calendar will appear in a dedicated section labeled "Link to calendar".