Accommodating non-github group members

[kcoyle]

So github has become the "hammer" that is nailing most working group activity. Although learning github is not rocket science, not everyone who could provide valuable input to a working group is git-enabled. This is especially true of folks with non-coding background but whose writing skills could help us produce clear, readable documentation. Add to this that editing documents as Respec code is gawd-awful, and some folks run away screaming.

My first concern is that folks who do not git are sometimes treated as somehow deficient or not qualified to participate in the production of working group deliverables. There is a bit of "git-snobbery" that needs to be countered by chairs and others. My second concern is that we need to find a way to enable editing by folks who don't git and who aren't able to hand edit html code. I have seen this: https://www.w3.org/2003/Editors/#authoring
but it doesn't seem to answer my question. I would like to know if anyone else has found a work-around for this "problem". (Which I consider to be a process problem, not a "lack of skills" problem.)

[BigBlueHat]

Single files can be edited directly on GitHub making it a bit like a wiki or minimal CMS. Sadly, it's not always clear from any given page what it's GitHub equivalent location would be, nor that one could "click edit" on arrival. Thankfully, though, that can be fixed easily enough...it just has to be remembered/done/etc.

Regardless, 👍 to making any and all of this easier for more people.

[kcoyle]

Thanks, @BigBlueHat. In my experience, groups don't want anyone to directly edit github pages even though the possibilities for backing out are the same as for merges. I suppose this is a holdover from using github for code rather than for documents, and it's not bad as a practice. There are document editing platforms, like Google Docs, that keep a history and can back out changes, but there's no wyswig editor in the W3C space (and it would need to translate to respec - that would be pretty difficult). I'm just brainstorming here: could all of this be easier, less of an effort, save the time of the WG members, be able to bring in a wide range of communities?

[plehegar]

Each community/group have their preferences in mode of interaction. That's the same for Chairs as well. Here, we're proposing GH (which a large amount of our groups are using) and email. Having a separate page into some wiki would disperse the resources I fear. Ideally, we should give write access to all Group chairs for the Guide repository. It's a resource for Chairs, so they ought to be able to edit it. This is an other use case for w3c/modern-tooling#58 in my mind.

[kcoyle]

@plehegar I'm not sure what you're referring to as "here". Maybe this has been confused with another discussion? This was a general discussion about seeking tools to make editing of WG documents easier to accommodate folks who find github to be a barrier.

[nrooney]

• Github guidelines and instructions can be includes in /guide
• Git and Github differences should be understood; git is relatively universal

What is the issue here? If one of the above then we have some workarounds, if it's regarding accounts, or something I'm not picking up on - let's discuss to find a way to move forward!

[nrooney]

Add github issues to /guide

[nrooney]

Check guides are in other languages

[kcoyle]

@nrooney Although you say that "git is relatively universal" it is so within a limited set of people. The issue is that for folks coming from non-programming backgrounds, github is not easy to learn. I know that it seems intuitive to those who use it daily, but it's a struggle for others. To expand the range of participants, especially for the editing of long and complex documents, I would like to encourage some thinking about how to make this easier. We should also think about accessibility issues (I can try to find some blind folks who have encountered git).

[plehegar]

we have accessibility related groups using GitHub. We have a blind chair using GitHub. We are aware of accessibility issues related to GitHub but haven't compiled them yet and send them to GH. I'd be happy to introduce to some of the accessibility experts in our community at TPAC if you'd like to.

[nrooney]

Continues in the /guide repo on w3c/guide#22