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 > > > > >
