Lightweight issue tracking with Smallest Federated Wiki

[kbigler]

My discovery of Smallest Federated Wiki coincided with a recently renewed wish for a way to have some accountable tracking within a small development company that is run in a very informal way due to the personalities involved. I saw the presentation of Smallest Federated Wiki as indicating an almost direct answer to the needs I'd been perceiving and the kind of solution I'd been wishing for. With minor tweaks (plug-ins, I hope) we could "use Smallest Federated Wiki for everything" and notably stop most current uses of email.

I imagine that a couple of new plugins might bridge the gap between what you have now and what we need to be productive given the both informal and diverse styles of this small company I'm involved with. But before getting into implementation I'd like to share an overview of the basic capabilities I envision and what these capabilities would replace. Then maybe you could suggest an approach.

Goal: to be able to create trackable items within narrative contexts. It is adequate for our needs to consider the trackable items to be of two types:

(1) issues (bugs, etc.)

(2) questions that one of us needs an answer for from another in our small group (usually only 2) in order to proceed with our work

We currently use email and an occasional "word file" and play it all very loose, and this is proving to be more dysfunctional as time passes in the context of changes this company is going through.

In our internal communication, I'd like to be able to talk about a scenario and in the midst of that scenario point out several things that are wrong and should be fixed. The accountable entities might simply be embedded internal links, but it might even be nice to have the full (probably brief) description be both typed in-line and appear in-line rather than opening the linked page for typing in ordinary use. Elsewhere there'd be a way to pull up a list of issues by keyword (e.g. project/milestone). It might be nice to be able to have automatic back-links to the narrative within which the issue was created.

Likewise I'd like to be able to type a narrative with embedded questions needing answers, and be able to expect that the reader therefore has some support for finding the things needing answers and a way to find them readily, 2 weeks and 1000 emails and one business trip later.

Secondarily, it is very good (and you already do this) that my narrative could be edited by my client into her own narrative, more useful for her to work with than the one I wrote, yet still contain the same embedded "imperatives".

Make sense? Do you agree that S-F-W is a match? [And how's S-F-W versus SFW as an abbreviation?]

[GerryG]

I can offer a number of promising directions to look for something a bit more "ready to deploy" as well as experiment/build with.

I work on Wagn (http://wagn.org/ and at github) which is a fully developed Wiki with advanced features that make issue tracking type apps pretty straightforward to implement. As for trackability, I have something I'm working on as a plug-in to wagn (we call them "Packs" in keeping with our model of "Cards", our objects that then compose pages). It is part of the Metacurrency project. I had it working on a much earlier version of Wagn and we have been making Wagn more modular and creating the Pack API with extensions like this in mind as we build. Long story short, I'm almost back around to having my Pack with the new API.

What that pack does is create a cyptologically signed audit trail of "Metacurrency Flows", in other words a sequence of signed transactions. Metacurrency will also involve an open language to declare the transactional rules of a currency system. So the idea is that you would declare the currencies and flows of issue tracking, and any subscriber to these flows can reconstruct the "state of play" in the currency system. That is count and display open, closed, in process issues as well as tracking and analyzing all of this through time.

[GerryG]

And, I agree with your motivations for looking at SFW, I'm here because I want to be able to connect Wagn as a Federated Wiki, and share content as this network develops.

I want to make sure that when Wagns Federate in this sense they get the maximum benefit of the fact that they share a lot of structure and convention, but I also want other Federated implementations to optionally share this structure and convention as well if they can interpret the features.

[WardCunningham]

Wagn has some very original ideas that have developed nicely. I'm flattered that there is interest in federating our two systems. Wagn is certainly more production ready and might be a great choice for small group issue tracking.

[WardCunningham]

I have done an experiment with modeling complex enterprise data, many thousands of pages, in a federated wiki. Different stakeholders can negotiate changes by forking the pages they'd like to see changed. Visualizations would show the impact of respective changes. Competing interests could fork parts of each others proposals until all are happy and the new system allowed to go live.

[kbigler]

Thanks for all the input. Here's what I'm thinking.

I think SFW is currently a blank slate in relation to "tracking" as I'm using the term. Working in blank-slate scenarios is something I inherently take to. But it also creates the opportunity to discover what the very minimum structure is that will satisfy a certain class of tracking needs. The organization I have foremost in mind does not need any more structure than necessary influencing native styles of working. And this experiment should [imperative] reveal some things that are more broadly applicable.

One way to approach this is to use this as my initial project for learning SFW. Toward that end please offer advice about how best to use what you have here, including the github issue tracking structure. It could be that we just keep this issue open for a while and it becomes the forum in which I present scope and design ideas and get feedback on that and also get help with the process of learning SFW as needed.

I would almost undoubtedly end up implementing plug-ins and I'd suppose that now and then the ensuing dialog would lead to a consensus for some base changes to SFW. I'd be glad to work on those as well as on other things not specifically pertaining to "my project" but which no doubt relate to my interests since I have general interest in SFW.

I'm not interested in maintaining a separate branch in the forseeeable future, or if possible, ever. I want to stay within a bounds of simplicity that allow for the most ease and convergence, aka sanity when you want to have a life. (I have a day job, too.)

So I propose to present design ideas right here as long as they remain basic, and spawn another github issue whenever one of them gets involved. If that seems reasonable I'll start as soon as I can digest some of the SFW basics. I plan to start with something ever so simple so that the entire scope can be readily grasped including how it fits in with SFW, plug-ins, and federation. No doubt I'll have to edge toward an understanding of the implications.

If it seems better to close this issue and open other issues as needed, let me know.

I will also want to be asking for guidance on how to learn SFW technically and that may present itself rather quickly as a candidate for a separate issue. Maybe that process would lead to development of the SFW github wiki pages, which I could contribute to. At the moment I have no idea how everyone else here doing significant development managed to get "in sync".

But for the moment there is already enough material I haven't yet digested. That may slow my start.

[WardCunningham]

Enough discussion for now I think.