[Ssr2-review] SSR2 document naming structure

[ALAIN AINA]

> On Apr 27, 2017, at 8:04 PM, dmb at donblumenthal.com wrote:
> 
> I like the structure but would add a description of the subject to the filename where appropriate; e.g., add the topic when SlideDeck is the sub-descriptor.


I agree and support this suggestion


> On Apr 27, 2017, at 2:59 PM, James Gannon <james at cyberinvasion.net> wrote:
> 
> This looks good to me, can I suggest that on the wiki that we keep a living list of both the subgroups and sub-descriptors for the team to reference.

Yes.

Will we have a private section(password protected) on the wiki for some documents ?

> 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 <mailto:jennifer.bryce at icann.org>
> Sent: Thursday, April 27, 2017 6:55 AM
> To: SSR2 <mailto:ssr2-review at icann.org>
> 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
> 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:
> Meeting-(date)-(sub-descriptor) – I would suggest using this descriptor for all non-Face-to-Face meetings of the RT.
> Date –Recommend using YYYYMMDD as in 20170411. This will keep the files in chronological order when you sort them.
> 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.
> 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:
> DRAFT
> FINAL
> RED-LINED
> CLEAN
> PUBLISHED
> 
> 
> 
> 
> --
> Jennifer Bryce
> Senior Reviews Coordinator
> Internet Corporation for Assigned Names and Numbers (ICANN)
> 
> Email: jennifer.bryce at icann.org <mailto:jennifer.bryce at icann.org>
> Skype: jennifer.bryce.icann
> www.icann.org <http://www.icann.org/>
> 
> _______________________________________________
> Ssr2-review mailing list
> Ssr2-review at icann.org <mailto:Ssr2-review at icann.org>
> https://mm.icann.org/mailman/listinfo/ssr2-review <https://mm.icann.org/mailman/listinfo/ssr2-review>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ssr2-review/attachments/20170429/fb69753a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/ssr2-review/attachments/20170429/fb69753a/signature.asc>