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