[Ssr2-review] SSR2 document naming structure

Bernard Turcotte turcotte.bernard at gmail.com
Mon May 1 23:16:32 UTC 2017


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 <aalain at trstech.net>
> *Sent: *Friday, April 28, 2017 4:57 PM
> *To: *SSR2 <ssr2-review at icann.org>
> *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 <jennifer.bryce at icann.org>
> *Sent: *Thursday, April 27, 2017 6:55 AM
> *To: *SSR2 <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
>
> 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/29bab5e2/attachment.html>


More information about the Ssr2-review mailing list