please excuse my barely coherent writing. we're having a heatwave in Germany ^^
On Mon, 3 Jun 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 >> > >> > >> >
