PLEASE NOTE: this thread should be moved to d...@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 <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 >> >