Re: Community Exclusion, was Fwd: GSuite Team Drive

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

PLEASE NOTE: this thread should be moved to dev@diversity.apache.org.
please subscribe to that list, and if you are sending a reply, please
remove diversity@apache.org from the address field

On Mon, 3 Jun 2019 at 17:44, Naomi S <no...@tumbolia.org> wrote:

> snap :)
>
>
> https://lists.apache.org/thread.html/a2bfc1c97d5460352c13fd80eac359b7262d76a2cf4f68e48fde30b9@%3Cdev.diversity.apache.org%3E
>
> On Mon, 3 Jun 2019 at 17:34, Luciano Resende <lu...@gmail.com> wrote:
>
>> How about opening a github issue for the documents that are being prepared
>> and a link to the google doc on its description? This should enable
>> visibility and mailing list notification.... a central place to see all
>> documents that are in progress... and still enable the usage of external
>> tools such a google docs ?
>>
>> On Mon, Jun 3, 2019 at 17:08 Naomi S <no...@tumbolia.org> wrote:
>>
>> > I agree with Myrle
>> >
>> > for anything that boils down to editing prose, Google Docs is my choice
>> of
>> > tool. for all the reasons she listed. and I say this as someone's who
>> day
>> > job is technical writing/editing
>> >
>> > PRs, JIRA tickets, etc are good for resolving issues and keeping track
>> of
>> > projects. wikis are good for collecting information. but for
>> > collaboratively drafting text, nothing really comes close to Google
>> Docs at
>> > the moment
>> >
>> > there are alternatives that don't require a Google account (
>> > https://etherpad.org/ for example) but they tend to lack things like
>> > comment workflows, suggested edits, and so on
>> >
>> > despite having said all this, I want to caution against getting too
>> hung up
>> > on tooling. this is an incredibly tempting issue to bikeshed check heck
>> out
>> > of and we risk sapping contributor energy
>> >
>> > that's not to say that it's not important to think about how the tools
>> we
>> > use may limit or stifle contribution. of course, that is of paramount
>> > importance. but it is to say that I think, with the experience, we have
>> on
>> > this committee, I think we can hopefully play this by ear and adapt as
>> > necessary
>> >
>> > my general advice is to let people try whatever tools they want and see
>> if
>> > it gets enough traction (which indicates people are finding it useful).
>> > then, at that point, you can look at how the workflow might be improved
>> >
>> > assuming that no OBVIOUSLY mistakes are being made, overthinking this
>> > stuff, more often than not, just contributes "stop energy" to volunteer
>> > efforts. and that's what I am most concerned about avoiding at this
>> stage
>> > of the committee
>> >
>> > On Mon, 3 Jun 2019 at 13:15, Myrle Krantz <my...@apache.org> wrote:
>> >
>> > > Sorry all,
>> > >
>> > > I have to disagree.
>> > >
>> > > Confluence is fine for public-facing stuff.  But for stuff that's
>> still
>> > in
>> > > work, it just doesn't support collaboration or document structure at
>> the
>> > > level that google docs do.
>> > >
>> > > The following (at least) is missing in confluence (and unthinkable in
>> > > email):
>> > > * Inline edit suggestions,
>> > > * anchoring comments to particular pieces of text,
>> > > * interactions on those suggestions and anchored comments
>> > > * A resolution workflow for comments.
>> > > * A tracked relationship between a version and a comment/suggestion.
>> > >
>> > > You can do this stuff to some extent in git, but workflows which
>> require
>> > > git won't be inclusive for people coming to our communities from
>> > conference
>> > > organization roles or documentation roles, and these are the people
>> with
>> > > the most know-how to contribute to D&I work.
>> > >
>> > > We have some control over the degree to which google docs are open or
>> > > visible (sharing permissions), and we should use that control.  Google
>> > docs
>> > > are transparent, and asynchronous.  Some of our developers will need
>> > learn
>> > > to use the technology, but the UX work done on google docs is for
>> > > non-specialist level users, so we should be able to do it too.
>> > >
>> > > Very few people (if any at all) can follow email threads which branch
>> and
>> > > weave and jump unless they are reading and responding in real time.
>> But
>> > > asynchronous collaboration is one of our major goals.
>> > >
>> > > (But I'll accept it if y'all want to go another way. : o)
>> > >
>> > > Best,
>> > > Myrle
>> > >
>> > >
>> > > On Mon, Jun 3, 2019 at 12:03 PM Bertrand Delacretaz <
>> > > bdelacretaz@apache.org>
>> > > wrote:
>> > >
>> > > > On Fri, May 31, 2019 at 2:45 AM Justin Mclean <
>> > justin@classsoftware.com>
>> > > > wrote:
>> > > > > ...I also don’t see the need for the google drive and would prefer
>> > that
>> > > > we use something more
>> > > > > in the open and visible like the wiki (confluence)....
>> > > >
>> > > > Big +1 to that as I said in another thread.
>> > > >
>> > > > -Bertrand
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: diversity-unsubscribe@apache.org
>> > > > For additional commands, e-mail: diversity-help@apache.org
>> > > >
>> > > >
>> > >
>> >
>> --
>> Sent from my Mobile device
>>
>