What would federated kanban be like? #105
Comments
|
As a point of reference, consider "Host your tiddlywiki in Gitlab pages without any git knowledge or installing any software" at https://gitlab.com/danielo515/tw5-auto-publish2gitlab-pages , and discussion at https://groups.google.com/forum/m/#!topic/tiddlywiki/s8pnvQW5UgY |
|
You are pointing at what interests me almost most in federated wiki. Placing panels of pages next to each other in a lineup quickly resembles a Kanban board, if they only contain bullet points and small chunks of issues/todos. Also the drag and drop workflow feels very familiar. On a second view, these engines are diagrammatic visualisations of data that makes use of the topological properties of the knowledges at hands. In this perspective, federated wiki already is a Kanban flow engine, as it easily allows to represent such views on a two dimensional surface. A notion we were exploring within the nested wikis discussion was that of a three dimensional wiki, in which pages afloat alongside multiple dimensions (lineup left > right, history front > back, links one wishes to unfold in a second dimension top > down). Informed by this, we could see the cards living on a Kanban page as embedded pages, which would unfold in a second lineup, instead of overwriting the current one. Then we'd have the commonly known way of being able to interact with an information space via the Kanban methodology (Trello, Wekan, Kanboard, ...) mapped into wiki. |
|
(I guess this issue is best placed in https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/ for discussion, as it is not strictly a technical issue with the NPM |
|
@jon r ... I want to follow this conversation, so if you're moving it
elsewhere, please post a link to this thread.
…On 14 August 2017 at 13:20, jon r ***@***.***> wrote:
(I guess this issue is best placed in https://github.com/
WardCunningham/Smallest-Federated-Wiki/issues/ for discussion, as it is
not strictly a technical issue with the NPM wiki package.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#105 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAFjdugHqGTuAfHJ8gdO2_Rdj_zXKjUiks5sYDuJgaJpZM4O0LPh>
.
|
|
There is no real reason to move this conversation... |
|
Kanban maybe useful to suggest wiki merges of wiki elements (as it is in
Git/Gerrit). We see useful merges of small text in Google documents
collaboratio, but we also see large scale arguments fostered in
Twitter. I'm assuming the smaller wiki elements can help consensus not
arguments. Adding Kanban per Joel's blog post perhaps moves wiki more to
horizontal application that vertical one. May need try to Kanban to observe
how Kanban fosters consensus or maybe drives other unintended interactions.
Perhaps depends on implementation.
…On Mon, Aug 14, 2017 at 12:04 PM, Paul Rodwell ***@***.***> wrote:
There is no real reason to move this conversation...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#105 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAsyruXpgJX6SrNrstP2vYV0eLC8xo7yks5sYJofgaJpZM4O0LPh>
.
|
|
On the Hangout today, I asked @WardCunningham about the idea of federated kanban. He said that he had previously seen Pivotal Tracker, and was impressed by the way they've implemented kanban (and how it ties to burndown, etc., making it a special-purpose tool for agile, rather than more general). The way in which people reach consensus on an agile project is different from the approach on federated wiki with multiple perspectives. This led to some discussion about a fedwiki paragraph being like a kanban card, and a fedwiki page being like a column in which the content could be moved. I said that I hadn't really appreciated that, as there's no visual cues on a fedwiki page that the paragraphs could be dragged and dropped (although I do know that is true). @opn brought up the idea of rosters (of people) where a dynamic group might write together. In addition, when pages get pulled in, and neighbourhood is also dynamic. This discussion led to Ward giving an online demo of graph that gets dynamically generated (that is code which he's got permission to open source, written in Neo4J). |
|
I mentioned some graph work I am doing at New Relic which I hope to have released into open-source in a month. I sometimes mention this work in federated wiki. Here are some links. |
I have been thinking about how people use wiki, as a broader technology. With the current federated wiki, the view is oriented towards two pages per screen.
An alternative view that is popular is kanban boards. However, I am thinking about wiki as a horizontal application in the sense that Joel Spolsky describes spreadsheets in https://www.joelonsoftware.com/2012/01/06/how-trello-is-different/ .
Some people use Tiddlywiki for personal to-do lists. Federated wiki could be a shared to-do list, but it's rather heavy weight for that. Trello is popular, but somehow doesn't have the piecemeal growth feel that wiki technology does.
The text was updated successfully, but these errors were encountered: