Try explaining that they can't push to the repo because they cloned the http URI and need to generate an RSA token and use SSH instead. Better yet, try to figure out that's the problem when they give you a totally unhelpful version of what the problem is.
Another not great but possible solution could be for non technical people to work on something like a Google Doc when stuff is in highly active development and to then copy this to a markdown document later when its solidified.
I do think that as a society we have to start looking at stuff like this as a new essential skill though. We wouldn't expect people to be working without basic literacy, numeracy and computer skills and I think we are going to have to start looking at upgrading our sense of what basic computer skills entails to include stuff like git and teaching it in schools from an early age.
And related to this is the state of WYSIWYG markdown editing.
The Basecamp folks created the very polished Trix rich-text drop-in which is a replacement for TinyMce, which while the standard seems to carry issues.
Basecamp explained the issue with most approaches as such:
> Most WYSIWYG editors are wrappers around HTML’s contenteditable and execCommand APIs, designed by Microsoft to support live editing of web pages in Internet Explorer 5.5, and eventually reverse-engineered and copied by other browsers.
> Because these APIs were never fully specified or documented, and because WYSIWYG HTML editors are enormous in scope, each browser’s implementation has its own set of bugs and quirks, and JavaScript developers are left to resolve the inconsistencies.
> Trix sidesteps these inconsistencies by treating contenteditable as an I/O device: when input makes its way to the editor, Trix converts that input into an editing operation on its internal document model, then re-renders that document back into the editor. This gives Trix complete control over what happens after every keystroke, and avoids the need to use execCommand at all.
Unfortunately Trix does not render markdown so can’t be used in a markdown documentation workflow.
Has anyone seen a decent implementation of WYSIWYG for markdown that has the necessary polish to be non-tech friendly?
https://discuss.codemirror.net/t/implementing-wysiwyg-markdo...
It's ok to be technical and not enjoy markdown, heh.
As much as I hate to admit it, sharepoint works better here.
On the upside for Google docs, commenting and edit suggestions work so well it’s become easier convince people to use Google docs without downloading copies.
How do you find a happy medium between this and a Confluence-like free-for-all, where anyone can create/edit a page?
But yes, the out of date info is a killer.
Given the number of non-programmers who Really Need the functionality of git, who probably won't be able to hack dealing with it, doesn't this indicate that there's some huge vein of untapped value to be won by whomever cracks the problem? (Version control for business people?)
I'm going to take a slightly different interpretation of your comment because I think it's an interesting discussion: are the non-technical people of today less technical than the non-technical people of the MySpace days?
From what I have observed, I would say yes. If you took the bottom 10% of users back then, you might have a hope of teaching them HTML. Today? No chance. In particular I think "willingness to learn anything" has really waned.
If there are more of them now it's probably because computer use expanded 100 fold since then, at least, and the largely self-selected 90s users of the Web, especially, tended to have greater-than-average interest in learning computer crap, so a high proportion of new users were the can't-or-don't-want-to-learn sort. In the 90s a computer still might not be the centerpiece of an office worker or middle manager's desk, and most folks used computers very little at home, if they even had one (data I'm seeing indicates % of households in the US with a computer only hit 50% in 2000).
And dealing with merges that involve only documentation in Markdown is similarly totally doable.
But then for actually releasing the docs, or tying them to feature commits etc., that all has to be done by actual devs. Also the creation of branches.
Also, people working on documentation in a software company aren't exactly "non-technical". They might not be full engineers but they can definitely handle files and some light version control.
This is far more difficult than you're suggesting. Git still confuses a lot of junior and mid level devs the second anything deviates from their memorized command workflow.
If you're expecting non-technical people to have to learn git just to edit the documentation, they're just not going to use it at all.
Writing and aggregating good documentation needs to be easy and simple. Gating documentation behind git is the opposite of that for non technical people.