[Ssr2-review] SSR2 document naming structure

dmb at donblumenthal.com dmb at donblumenthal.com
Tue May 2 01:38:35 UTC 2017


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 at 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 at 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 at icann.org
Skype: jennifer.bryce.icann
www.icann.org
 
_______________________________________________
Ssr2-review mailing list
Ssr2-review at icann.org
https://mm.icann.org/mailman/listinfo/ssr2-review
 
 

_______________________________________________
Ssr2-review mailing list
Ssr2-review at icann.org
https://mm.icann.org/mailman/listinfo/ssr2-review


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ssr2-review/attachments/20170501/ef8fe1c8/attachment.html>


More information about the Ssr2-review mailing list