I would support a central repository if ICANN had a true document management system. There were formal discussions about doing that a few years ago, but I don’t see where they have gone anywhere. I was part of some of them, and will try to put together some more details if anybody is interested. I don’t find Google Docs very helpful. Many ICANN groups that I have been a part of considered that system, and all decided to do edits using local files. Don From: ALAIN AINA Sent: Friday, April 28, 2017 4:57 PM To: SSR2 Subject: Re: [Ssr2-review] SSR2 document naming structure Also can we confirm that for group editing and collaboration that everyone is ok with the use of Google Docs? Force people to have a google account and export document. My 15 years experience at SSAC shows that editing  via local word docs work. Thanks —Alain     From: Jennifer Bryce Sent: Thursday, April 27, 2017 6:55 AM To: SSR2 Subject: [Ssr2-review] SSR2 document naming structure   Hi all,   We have created a draft file naming structure for staff to use for all documents shared with the SSR2 Review Team. The intention is to help the Review Team to quickly and easily identify the contents of a document and at what stage the document is in. It will also help support version control and allow easy archiving of documents.    You can review the details of the structure in the attached document - also pasted below. Let us know if you any concerns with this approach or would like to propose an alternative structure.     ---------------------- Draft file naming structure for SSR2-RT   This is based on the work done on the CCWG-Accountability WS1 and 2 to some extent.   CCWG-Accountability-WS2-Plenary20170412-AgendaV1.0BT   The intent is to create a filename that is independent of internal filing system attributes (eg. dates) so the reader can simply and quickly identify what the contents of that file should be and by whom is was produced.    File naming convention. – composed of: • Project tag: SSR2 o All files produced for this project should have this tag as the first part of the filename. Other reference material may also be tagged with this if useful but the filename would have to reference this. • Sub-groups: If the RT creates a sub-group to deal with SSR1 recommendations the this could be SSR1RecsSG or SSR1Recommendations – in this case this would create SSR2-SSR1RecsSG. A good starting point for these can be the names of mailing lists for the project as such SSR-Coordination could be used for Co-Chair/Staff work and meetings. What is important is to keep a living list of these. • Descriptor – This is really the most complex one where we will have to agree to a list of these for the common things. Here are some suggestions of some of the more commonly used ones: o Meeting-(date)-(sub-descriptor) – I would suggest using this descriptor for all non-Face-to-Face meetings of the RT.  o Date –Recommend using YYYYMMDD as in 20170411. This will keep the files in chronological order when you sort them. o Sub-descriptors might include: • Agenda • SlideDeck • Notes • ActionItems • Recordings • Transcriptions • Presentation • FacetoFaceMeeting-(date)-(sub-descriptor) • Report (As with the previous point what is important is to keep a living list of these for the team.) • Version – VX.Y (eg V1.0) where X is for major versions and Y is for minor versions. You can extend either into multiple digits (eg V1.12). Usually starting at V1.0 for a new document although some people like to start at V0.1 when producing the first few versions from scratch and then move to V1.0 once its shared. o If someone edits a document in any way then they should update the version number accordingly and ensure they note themselves as the Author (next field). • Author(s) – In small groups a person’s initials are usually fine. Only one set of initials should be included.  Adding initials to the previous ones there can lead to confusion. • Status – This field is optional and a bit of a catch all. It could be used for any of the following types of information: o DRAFT o FINAL  o RED-LINED  o CLEAN  o PUBLISHED          --  Jennifer Bryce Senior Reviews Coordinator  Internet Corporation for Assigned Names and Numbers (ICANN)   Email: jennifer.bryce@icann.org Skype: jennifer.bryce.icann www.icann.org   _______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org https://mm.icann.org/mailman/listinfo/ssr2-review

I apologize. In fact I had planned a “never mind” note after coming across the initial message in the thread. I’m thoroughly in the weeds because I was off the grid for a few days helping my mother celebrate her birthday, and wasn’t necessarily reading emails in the right order. My opinion of Google Docs remains, but it’s irrelevant to the document naming message. Don From: Bernard Turcotte Sent: Monday, May 1, 2017 7:16 PM To: dmb@donblumenthal.com Cc: ALAIN AINA; SSR2 Subject: Re: [Ssr2-review] SSR2 document naming structure All, 1 The suggestion was for a file naming structure regardless of where the documents live. 2 DMS is ideal but we do not have that option - however having a common repository for common files is still a big advantage  over not doing so especially when conforming to a standard file naming structure. Additionally real DMS systems do require a fair amount of up front work which for a large organization is worth it - for a small group like SSR2 uncertain. 3 I do not think anyone was suggesting having to work with Google docs for editing - its not bad as a basic word processor but a hard sell for people who have been using Word or other such tools for years - especially if someone has any kind of connectivity issues - and this project is about efficiency so any format that can be uploaded and downloaded easily and efficiently to a Google docs folder should be acceptable. I will note that the real-time multi-editor function of Google write does work very well when a group has do simultaneously work on a document - but that is a different paradigm which we probably only need to focus on for special cases. The decision is that of the RT but given what we have available it would seem that a standard naming structure for files combined with a common google based repository for files would provide us with maximum value for minimal investment and pain. Cheers Bernard Turcotte ICANN Staff Support to the SSR2 On Mon, May 1, 2017 at 6:38 PM, <dmb@donblumenthal.com> wrote: I would support a central repository if ICANN had a true document management system. There were  formal discussions about doing that a few years ago, but I don’t see where they have gone anywhere. I was part of some of them, and  will try to put together some more details if anybody is interested.   I don’t find Google Docs very helpful. Many ICANN groups that I have been a part of considered that system, and all decided to do edits using local files.   Don   From: ALAIN AINA Sent: Friday, April 28, 2017 4:57 PM To: SSR2 Subject: Re: [Ssr2-review] SSR2 document naming structure Also can we confirm that for group editing and collaboration that everyone is ok with the use of Google Docs?   Force people to have a google account and export document. My 15 years experience at SSAC shows that editing  via local word docs work.   Thanks   —Alain         From: Jennifer Bryce Sent: Thursday, April 27, 2017 6:55 AM To: SSR2 Subject: [Ssr2-review] SSR2 document naming structure   Hi all,   We have created a draft file naming structure for staff to use for all documents shared with the SSR2 Review Team. The intention is to help the Review Team to quickly and easily identify the contents of a document and at what stage the document is in. It will also help support version control and allow easy archiving of documents.    You can review the details of the structure in the attached document - also pasted below. Let us know if you any concerns with this approach or would like to propose an alternative structure.     ---------------------- Draft file naming structure for SSR2-RT   This is based on the work done on the CCWG-Accountability WS1 and 2 to some extent.   CCWG-Accountability-WS2-Plenary20170412-AgendaV1.0BT   The intent is to create a filename that is independent of internal filing system attributes (eg. dates) so the reader can simply and quickly identify what the contents of that file should be and by whom is was produced.    File naming convention. – composed of: • Project tag: SSR2 o All files produced for this project should have this tag as the first part of the filename. Other reference material may also be tagged with this if useful but the filename would have to reference this. • Sub-groups: If the RT creates a sub-group to deal with SSR1 recommendations the this could be SSR1RecsSG or SSR1Recommendations – in this case this would create SSR2-SSR1RecsSG. A good starting point for these can be the names of mailing lists for the project as such SSR-Coordination could be used for Co-Chair/Staff work and meetings. What is important is to keep a living list of these. • Descriptor – This is really the most complex one where we will have to agree to a list of these for the common things. Here are some suggestions of some of the more commonly used ones: o Meeting-(date)-(sub-descriptor) – I would suggest using this descriptor for all non-Face-to-Face meetings of the RT.  o Date –Recommend using YYYYMMDD as in 20170411. This will keep the files in chronological order when you sort them. o Sub-descriptors might include: • Agenda • SlideDeck • Notes • ActionItems • Recordings • Transcriptions • Presentation • FacetoFaceMeeting-(date)-(sub-descriptor) • Report (As with the previous point what is important is to keep a living list of these for the team.) • Version – VX.Y (eg V1.0) where X is for major versions and Y is for minor versions. You can extend either into multiple digits (eg V1.12). Usually starting at V1.0 for a new document although some people like to start at V0.1 when producing the first few versions from scratch and then move to V1.0 once its shared. o If someone edits a document in any way then they should update the version number accordingly and ensure they note themselves as the Author (next field). • Author(s) – In small groups a person’s initials are usually fine. Only one set of initials should be included.  Adding initials to the previous ones there can lead to confusion. • Status – This field is optional and a bit of a catch all. It could be used for any of the following types of information: o DRAFT o FINAL  o RED-LINED  o CLEAN  o PUBLISHED          --  Jennifer Bryce Senior Reviews Coordinator  Internet Corporation for Assigned Names and Numbers (ICANN)   Email: jennifer.bryce@icann.org Skype: jennifer.bryce.icann www.icann.org   _______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org https://mm.icann.org/mailman/listinfo/ssr2-review     _______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org https://mm.icann.org/mailman/listinfo/ssr2-review