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 <n...@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 <luckbr1...@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 <n...@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 < > > > > bdelacre...@apache.org> > > > > wrote: > > > > > > > > > On Fri, May 31, 2019 at 2:45 AM Justin Mclean < > > > jus...@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-unsubscr...@apache.org > > > > > For additional commands, e-mail: diversity-h...@apache.org > > > > > > > > > > > > > > > > > > > -- > > Sent from my Mobile device > > > -- Gav...
