Sven's curiosities about smallest-federated-wiki HOT 5 CLOSED

Sven -- I'm thrilled that you've found the code provocative. I've found that most things I try to do are easier than I thought and then immediately suggest even cooler things to try. There are a number of smaller things that I've just left out because thinking them through hasn't been a priority.

For example, I've assumed that I would write a page title to slug converter soon enough (Welcome Visitors => welcome-visitors). In its absence I've just written slugs in links [[welcome-visitors]] instead of the more desirable title [[Welcome Visitors]]. (See commit and comments at 6332145) In the same way I've used HTML tags instead of markup, a practice that is very dangerous.

I've resisted making the system usable for creating content independent of the JSON underneath. Hacking the JSON directly is a good way to get a feel for what sort of things the software could do. I'm especially interested in having a lot less markup than wikis have right now, and maybe diverse markups based on item.type (say, a calculator markup, or even reinventing mathematics in ways suggested by "Kill Math".)

So, by all means, hack the code to try anything that comes to mind. Lean from coding. Find out what federated wiki wants to be. Please, share you discoveries here so we can all learn from your experiments.

And, open issues when you feel I should be working somewhere, or when you're about to work somewhere and want to know what I or others have been thinking. Healthy open source projects make important decisions in public. We'll get healthier as we practice this. Let's close this issue once we've taken all the points you've raised and created issues for each of them.

And, put up a server or two running any old code base that you think might federate. Change it often. Move pages back and forth. That is how we will learn what has to be held stable (and what doesn't) to keep a federation of servers vital. I'll make a list of interesting servers on this site's wiki. That can be our bootstrap until the federated wiki is complete enough to reliably host its own content.

Thanks for joining us. -- Ward

from smallest-federated-wiki.

The list of federated wiki pioneers appears here: https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/List-of-Pioneers

from smallest-federated-wiki.

I'm especially interested in having a lot less markup than wikis have right now, and maybe diverse markups based on item.type (say, a calculator markup, or even reinventing mathematics in ways suggested by "Kill Math".)

now that gives me an idea - I'll re-write the star list rendering as a seperate item. I also get the feeling that you're trying to force pages to be broken up, avoiding the double-return mess we have in existing wiki's.

which is another thing - atm, it breaks the writing flow to click 'add factory' rather than just hit return twice - so maybe I'll find a way to get the textarea to detect 'newParagraph' events.

the hard issue is how to allow the user to select a paragraph type - prose (what there is now), list (what I'll try out), etc.

from smallest-federated-wiki.

Here is an expense calculator I wrote 30 years ago.I was thinking it might make a good demo. Would have to translate AWK to CoffeeScript. Might be good to see the calculator work at the unix command line first.

http://c2.com/doc/expense/

from smallest-federated-wiki.

I'm going to close this issue under the assumption that Sven's Curiosities have been addressed. Just to be sure, I summarize as follows.

1. make everything plugged -- title is special because it generates url & db key. I'd like to have some Mediawiki automatic redirect on rename. About half the names in Wikipedia are redirects. The slug-making is first step. Thanks. Further discussion in new issue.
2. groups of pages as a forkable unit -- Interesting idea. We are certainly encouraging small pages. Acknowledge this as opportunity.
3. local storage just like another server -- Agree. Will do this when the fork-on-edit logic is undertaken. Right now the notion of remote is too incomplete to work on this now.
4. distributing code as content -- I'm hesitant to do this in that I'd like the JSON to be inert. A similar suggestion is that any story item of other than most familiar type (paragraph, image) should have a "git" parameter that cites an open-source plugin implementation.
5. documentation -- goals here are: (a) house-clean the wiki to be as-built plus roadmap for new developers (b) an interactive tutorial, maybe made by playing back an annotated journal.

from smallest-federated-wiki.