Thoughts on merging nationofmakers/documents with MCP series
stevegt opened this issue · comments
The MCPs are currently hosted as gdocs; current frontend is http://bit.ly/mcp-index. There are a lot of tools that can convert gdocs to markdown, preserving revision history. MCP-1 is the draft doc for migrating to github.
A major issue with migrating to github is familiarization; most NoMers to date seem much more comfortable with gdocs.
Another major issue is the live collaboration features of gdocs -- critical during meetings, breakouts, and conference calls. Etherpad would be able to supply that feature, but we'd want to use markdown and git as the backend, which would take some hacking on etherpad iirc.
A possible solution might be using etherpad as the master, with mirroring to github or gitea.
What would the rationale be for migrating/merging? So far your thoughts seem to be in favor of maintaining gdocs - lots of good features that folks are familiar with.
Please note: I'm not inherently opposed to GitHub, it just seems a bit clunky to me (mostly because I am one of the NoMers who is woefully ignorant about it :-)).
Funny you should ask; lemme get philosophical for a moment -- I'll get practical again, but want to lay some groundwork first...
The MCPs are an RFC series -- a long-term community-maintained document store that transcends the turnover of individuals, institutions, or hosting services.
In the maker community, I think we're somewhere around the year 1969 and Internet RFC 3. We still only have a faint clue how this thing is going to work or how it's going to impact the world -- it's pure science fiction at this point, and we're all underestimating it. As with the MCPs today, many of the RFCs in 1969 are just recording meeting minutes or even just thoughts and conversations. In 1969 we don't even know the word "Internet" yet, and even "ARPANET" is still a year or two away. I think the term "maker community" today itself is more or less equivalent to the "network working group" you'll see mentioned in the early RFCs -- I think it's a stand-in for whatever name the world is eventually going to use for this cultural and economic sea change.
In that context, deciding whether we should be using gdocs or github is more or less equivalent to the NWG trying to decide whether to use A4 or US Letter sized paper for the RFCs. It's the wrong question. The network didn't really take off until it bootstrapped to the point where it could host the RFCs themselves, and they became a dynamic electronic resource; that enabled communications and consensus-forming to a degree that wasn't possible in prior human history.
I think a similar thing is going to happen with the MCPs -- the maker community, or whatever it evolves into, will not truly find itself until it begins to self-host its own store of knowledge and method of consensus.
I don't know what form that self-hosting will take, but I do know gdocs isn't it. If I had to guess right now, I'd say it will probably be a distributed data structure of some sort; this releases us from the constraints or outage of any single host or server, and enables us to take advantage of the unique talents and perspectives of makers and their facilities.
Right now, the most mature distributed data structure we have is git. Note that I'm saying "git", not "github" -- there's nothing wrong with github, but it's just one git host. Git, being a DVCS, transcends that dependency on one host or organization.
Something will eventually replace git -- it might be some blockchain-based thingy, or it might be something else that hasn't emerged yet. But the precedent set so far is that, once your documents are hosted in one of the distributed data stores, migrating from one generation of storage to the next is trivial -- someone will write a migration tool. The job we have ahead of us is to get into one of those data stores in the first place.
In a practical sense, gdocs is already problematic for storing the MCPs because:
- Links to docs are dependent on google -- we're already locked in, and this will only get worse.
- With no folder structure, relative links are impossible, forcing us to use the long google links even between docs.
- Google's long links are cumbersome but short links like bit.ly are fragile. We've already been bitten by bit.ly outages, and google has already deprecated the goo.gl link service.
- Editing permissions are dependent on having a google ID and being logged into a google site to be granted individual access to a gdoc -- our experience with the call notes tells us that most maker leadership folks don't do this, so we have to keep passing around public-editable links instead, and we've already had some vandalism via those links.
- Document ownership in gdocs is by individual gdrive accounts, meaning any document will disappear when its owner's account does. We could transfer all MCP docs into the ownership of one team account, but that ensures even more google lock-in, and given the individuality of makers I think that centralization will cause an ownership and control civil war which I'd rather see us avoid. The right way to do this in gdocs would be with a consensus-based review and editing workflow, but see the next bullet point.
- We need software support for review and editing workflow, but my experience writing bit.ly/mcp-index tells me that google's javascript-based Apps Script service is a cumbersome way to add these features. It executes slowly, so doing anything complex is pretty much out.
- Like goog.le links and Google Reader, anything google-based that we do pour effort into is subject to deprecation. Don't get me wrong; I like google's services so much that my own business relies on them extensively, but I carefully pick and choose what I think is likely to work going forward. I don't expect gdocs to go away, but I do expect it to change in ways that may be incompatible with what we need.
- As an illustrative example, Google has recently added the "This application was created by another user, not by Google" splash at the top of each and every Apps Script page. You'll see it at the top of bit.ly/mcp-index. We can't remove that, and just have to live with it.
There's more, but I think this may provide enough of a view into what I'm thinking. I'll likely post this message as an MCP itself after some cleanup, and more details may evolve there.
Thanks for the helpful info and primer, Steve!