You are viewing a plain text version of this content. The canonical link for it is here.
Posted to diversity@apache.org by Bertrand Delacretaz <bd...@apache.org> on 2019/06/03 10:03:12 UTC
Re: Community Exclusion, was Fwd: GSuite Team Drive
On Fri, May 31, 2019 at 2:45 AM Justin Mclean <ju...@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
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by 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
>>
>
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by Gavin McDonald <ip...@gmail.com>.
I think some people need to take a new look at the user documentation for
Confluence, it has loads of collaborative editing features - multiple
people editing the same page/document at the same time, inline comments and
a heap more besides.
https://confluence.atlassian.com/doc/collaborative-editing-858771779.html
etc...
Gav...
On Mon, Jun 3, 2019 at 4:45 PM 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
> >
>
--
Gav...
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by 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
>>
>
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by Naomi S <no...@tumbolia.org>.
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
>
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by Luciano Resende <lu...@gmail.com>.
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
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by Naomi S <no...@tumbolia.org>.
please excuse my barely coherent writing. we're having a heatwave in
Germany ^^
On Mon, 3 Jun 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
>> >
>> >
>>
>
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by Naomi S <no...@tumbolia.org>.
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 <ju...@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
> >
> >
>
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by "Kevin A. McGrail" <km...@apache.org>.
>
> whoever does the work decides which tool to use.
Huge +1 on this.
I would like to see someone do a spreadsheet in confluence and work on it
to come up with a budget.
Sam's work with custom scripts to do a FY budget is an example for me of
how to exclude people because it assumes programmers only. I couldn't fix
a single error I noted in it.
I like Myrle's idea of discoverability. We did the same in fundraising
with the fundraising.apache.org playbook site.
Regards, KAM
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jun 3, 2019 at 1:15 PM Myrle Krantz <my...@apache.org> wrote:
> ...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...
That's because quoting efficiently, branching threads when required
etc. are becoming a lost art unfortunately.
I suppose that's a fact so there's not much we can do about it, except
leading by example where we can.
> ...But asynchronous collaboration is one of our major goals..
Big +1 and I'd argue that documents are *not* a good way to make that happen.
Git tickets for example work extremely well IMO for asynchronous
collaboration on concepts, guidelines etc.
But as I said whoever does the work decides which tool to use.
And discussions about tools are hard.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: diversity-unsubscribe@apache.org
For additional commands, e-mail: diversity-help@apache.org
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by Myrle Krantz <my...@apache.org>.
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 <bd...@apache.org>
wrote:
> On Fri, May 31, 2019 at 2:45 AM Justin Mclean <ju...@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
>
>
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jun 3, 2019 at 1:14 PM Patricia Shanahan <pa...@acm.org> wrote:
> ...The Google Drive idea, even with a public
> list of documents, will make things private unless and until someone
> decides to make them public...
Good point - public by default + discoverable is how we should work.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: diversity-unsubscribe@apache.org
For additional commands, e-mail: diversity-help@apache.org
Re: Community Exclusion, was Fwd: GSuite Team Drive
Posted by Patricia Shanahan <pa...@acm.org>.
On 6/3/2019 3:03 AM, Bertrand Delacretaz wrote:
> On Fri, May 31, 2019 at 2:45 AM Justin Mclean <ju...@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.
+1
As someone who is not on the committee but interested in its work, I am
strongly in favor of documents being readable by all unless there is a
reason for confidentiality. The Google Drive idea, even with a public
list of documents, will make things private unless and until someone
decides to make them public.
---------------------------------------------------------------------
To unsubscribe, e-mail: diversity-unsubscribe@apache.org
For additional commands, e-mail: diversity-help@apache.org