Re: GSuite Team Drive

[Shane Curcuru <as...@shanecurcuru.org>]

Bertrand Delacretaz wrote on 2019-6-3 6:00AM EDT:
...snip...
> Shared documents work for me for short-term collaboration on polishing
> texts, but for the type of durable information that (I assume) most of
> the D&I work requires, wikis work much better for me.

For committee members working on new ideas or collaborating on a draft,
I think GSuite is a great idea - when the people actively collaborating
prefer using that.  For polishing explanatory documents, they are far
easier to explain and accept/edit text updates than other tools,
especially for those who are not primarily coders.

But I expect GSuite to be a starting collaboration area within the
active group here, not an area where we're trying to publish documents
for broader public review.  Once a document is at a final draft (or
similar) state, it should move to the website or wiki, for final
feedback and to be a public resource.

Thus, different tools for different stages of a document's lifecycle.

> If people who do the work go for the document style in GSuite, please
> at least provide a list of those documents at a stable public URL to
> help make them discoverable.

*This* is the biggest drawback to GSuite I see, even for committee
members otherwise actively contributing.  If you don't see the first
email that says "Hey, let's edit X over here...", then it's hard to
catch up and find the document (not otherwise findable) when you *later*
want to join the discussion in a later part of the thread.

-- 

- Shane
  Member
  The Apache Software Foundation

Re: GSuite Team Drive

[Naomi S <no...@tumbolia.org>]

On Mon, 3 Jun 2019 at 13:33, Shane Curcuru <as...@shanecurcuru.org> wrote:

> Bertrand Delacretaz wrote on 2019-6-3 6:00AM EDT:
> ...snip...
> > Shared documents work for me for short-term collaboration on polishing
> > texts, but for the type of durable information that (I assume) most of
> > the D&I work requires, wikis work much better for me.
>
> For committee members working on new ideas or collaborating on a draft,
> I think GSuite is a great idea - when the people actively collaborating
> prefer using that.  For polishing explanatory documents, they are far
> easier to explain and accept/edit text updates than other tools,
> especially for those who are not primarily coders.
>
> But I expect GSuite to be a starting collaboration area within the
> active group here, not an area where we're trying to publish documents
> for broader public review.  Once a document is at a final draft (or
> similar) state, it should move to the website or wiki, for final
> feedback and to be a public resource.
>
> Thus, different tools for different stages of a document's lifecycle.
>

+1

exactly what Shane said


> > If people who do the work go for the document style in GSuite, please
> > at least provide a list of those documents at a stable public URL to
> > help make them discoverable.
>
> *This* is the biggest drawback to GSuite I see, even for committee
> members otherwise actively contributing.  If you don't see the first
> email that says "Hey, let's edit X over here...", then it's hard to
> catch up and find the document (not otherwise findable) when you *later*
> want to join the discussion in a later part of the thread.
>

how about this, as a rule of thumb:

when you create a Google Doc, you should be a corresponding JIRA ticket
with the Google Doc URL listed somewhere

not only does that ensure that Google Docs get shared with the dev@ list,
it reinforces the idea that the life span of a Google Doc is tied to the
lifespan of a JIRA ticket, and that information should be migrated
elsewhere (if needed) when the ticket is closed