Long term solution for tracking issues & progress

[holtzermann17]

One of the things we have been talking about in the reading group is how our pattern catalogue is adapted to keep track of next steps in the project.

However since that hasn’t been kept up-to-date since we published the paper, we need some additional strategy for integrating patterns and to do items (especially if we are going to make the book pattern focused!)

[paolaricaurte]

I remember that in the Wikipedia community there was a platform where you had your tasks and the level of progress. It was very useful. Others could comment and also you could reassign the task. Not like Trello or other platforms.
About the paper, it was not formally published. One option is also to update the paper, that is easy to handle, and then continue with the book.
Off topic: how does this site on github look so nice? https://metalabharvard.github.io/

[holtzermann17]

Seems still open! Let's find the Wikipedia platform so we can learn from it.

[skreutzer]

One of the things we have been talking about in the reading group is how our pattern catalogue is adapted to keep track of next steps in the project.

However since that hasn’t been kept up-to-date since we published the paper, we need some additional strategy for integrating patterns and to do items (especially if we are going to make the book pattern focused!)

Please clarify. My interpretation attempt and current understanding: the pattern catalogue is based on a meta-pattern ("template") of "Motivation", "Context", "Forces", "Problem", "Solution" and so on, and in that scheme presents a few particular patterns like "Roadmap", "Reduce, reuse, recycle", "Carrying Capacity", and so on. The "published paper" is the handbook v3 or something else? Is there a difficulty or what would be the problem to add new patterns (not sure why and which new patterns would be needed, for what reason/need?)? For doing pattern things, it wouldn't be too hard to implement the meta-pattern (template) in software to become a pattern generator (and then a generic meta-pattern/template generator of course too), and new patterns generated this way could go straight into the catalogue, from where they could immediately update a PDF for print catalogue, databases, websites, cards, so people can update their pattern collection or share these in order to be used as tools in actual learning/teaching sessions.

I fail to connect to-do steps to it. Is this a request to add a "Todo" entry to the meta-pattern/template, or assign tasks for existing patterns in the catalogue to potentially update it, or something like this?

[skreutzer]

Off topic: how does this site on github look so nice? https://metalabharvard.github.io/

It pretty much seems to be the case that GitHub Pages (the stuff that can be found under subdomains of github.io) allows a large majority of regular website design/"programming", so it's less a question specific to GitHub in particular, but of web layouting in general (the HTML and CSS, being technically capable and creative with it). Or is this a question of who came up with that particular design, and why, and how others could potentially arrive at similar works as well? :-)

[holtzermann17]

So the key connection is that the pattern template used in the handbook includes something called a “next step.” This means that every pattern is both a observation on how things have been going, and a prediction of how things will go. If we don’t have a next step for a given pattern, then we don’t really need the pattern anymore. At least this is how it was supposed to work in principle. I am not totally convinced that this will actually work, but the idea is to use the design patterns to describe all of the work that we do in the project, therefore something like this should probably work even if the strategy needs some fine tuning. So for example all of the issues that appear inside of this issue tracker should in principle match to some pattern in the catalogue as some variant version or some instantiation of a next step. Getting all of this sorted out will require a lot of awareness and reflection and clear thinking and so on and so forth… And absolutely yes we will want some software in the mix too to make it all fit together. I hope this clarifies a bit anyway thanks! As for the distinction between the paper “Patterns of Peeragogy” and the collection of patterns in the handbook, there is really very little difference, we basically just wrote the paper and copied the contents into the handbook. But you can find the paper online as a standalone document as well as the book.

[skreutzer]

So the key connection is that the pattern template used in the handbook includes something called a “next step.”

OH, I see! I joined the reading group at chapter "K-12 Peeragogy", not reading the patterns in detail yet, so I missed the "What's Next" box at the end of each pattern because it's not a bold entry keyword. Legitimate, why should the meta-pattern/template consist all of the same elements, to the contrary potentially. Thanks for pointing that out. The pattern template table figure makes this clear as well.

(Side note: real-time, time-synchronized group progress might not be of use if other peers would have to join later, or waiting/inactivity isn't an option until the reading group restarts again, and in terms of hypertext theory, all just for the arbitrary reason that the text happens to be printed on the linear, sequential paper book medium of the non-digital, physical world, instead of having each chapter as a quest room with people to stay in or move on to the next hall by choosing one of the doors the player is currently most interested in, together with a guide or peers in this case pointing me to the pattern catalogue)

[skreutzer]

It should be possible relatively easily to extract all "Next Steps" from the pattern catalogue and look at these as a collection of issues to work on, but this isn't true the other way around, to use these issues on GitHub and add them as patterns to the catalogue because the other fields/entries of the meta-pattern/template would be missing, because GitHub Issues isn't that pattern generator, just an issue/Next-Steps tracker. What should be the policy: always create/demand a full pattern for every activity/task, or allow activities that aren't necessarily related to a pattern? Extra: filling up the template with some nonsense, just to fulfil the formal requirement of completing the template to track the work/progress on anything? Should work exclusively happen in the form of patterns, and if so, what's the advantage/benefit? Typical wider systemic considerations and a chance for reflection?

(Side note: we're abusing these comments to the Issue already for chatting/discussion, which may or may not be a bad thing.)

[holtzermann17]

This is the difficult part, I think - abstracting from the issues, or integrating them up into patterns. Ideally we would understand what we are doing well, with the benefit that the patterns describe effective, useful, intentional ways of interacting, where the assumption is that we don't quite have those by default. We do have instincts, and these may be the basis for the patterns, but learning what these instincts are and consciously using them takes it a step further. Here's a quote from the 2018 Nobel Memorial Prize in Economics winner:

"The raw materials that we use have not changed, but as a result of trial and error, experimentation, refinement, and scientific investigation, the instructions that we follow for combining raw materials have become vastly more sophisticated." (http://web.stanford.edu/~klenow/Romer_1990.pdf)

The hope is that we could achieve much the same here.

[holtzermann17]

(Side note: real-time, time-synchronized group progress might not be of use if other peers would have to join later, or waiting/inactivity isn't an option until the reading group restarts again, and in terms of hypertext theory, all just for the arbitrary reason that the text happens to be printed on the linear, sequential paper book medium of the non-digital, physical world, instead of having each chapter as a quest room with people to stay in or move on to the next hall by choosing one of the doors the player is currently most interested in, together with a guide or peers in this case pointing me to the pattern catalogue)

This suggests another advantage of connecting the patterns with issues, because items inside the issue tracker could then be these "quest rooms". The interactive version of the book would then be mirrored here (or in whatever medium the issues were being addressed). The linear printed view would just be one overlay on this. A bit like Ende's book "The Neverending Story", in which the book itself acts as a 'portal' to the fantasy world described in the book. (I should reread that over the holiday!)

[skreutzer]

I've re-read the exchange above and now think that it would be strategically best to not spend time and try to manage the activities for handbook v4, but instead use the handbook patterns + the pattern template + the After Action Review as source for new patterns, set it up as a semantic data project (potentially generic/universal enough so that it can cover some other pattern languages as well) and build the software + practices around it, bootstrapping and prototyping it forward, and be it as a learning course/exercise/journey.

[holtzermann17]

Handbook workflow and semantic data workflow seem related. Maybe all that’s really needed for managing the generation of new case study content is the existing outline in the Google Doc. Similarly, we have some standard technology in Google Docs for marking line edits. Managing the results of all this effort will benefit from some special purpose software that makes the structure explicit. So, setting this up does seem to be a priority, since it is a missing piece. My sense is that an improved way to manage issue tracking will be an immediate corollary of an improved way to manage patterns.

[skreutzer]

Generally agree, with the line of thinking that from the semantic data repository of patterns, either the pattern catalog part of the handbook or the (a new type of) handbook as a whole could be generated from it (basically a field handbook of patterns, less theoretical discussion of peeragogy theory). Could also be a separate resource (book, website, e-publication, apps, online software, cards, whatever).

Extracting the pattern descriptions from MarkDown (automatically or manually) and put them into a separate repository or section in the existing Peeragogy.github.io repository, or re-do the PeeragogyPatterns repository (seems to be a snapshot for generating the print PDF like the peeragogy-handbook repository was/is), and then generate MarkDown from the pattern format (or why would it be needed any more, could generate .tex directly from the source). If Peeragogy.github.io should be kept as the source and the patterns written in MarkDown, OK, that's an option as well, but would require some mechanism (maintained manually or automatically?) to tell the patterns apart from other content, and parse MarkDown to recognize the pattern structure (interpreting headlines as the pattern template/structure, figuring out what to do with the HTML in there that obviously doesn't belong into MarkDown anyway, somehow make sure that the reference and footnote scheme can be processed) – a lot of inconvenience for little gain, where there could be custom editor tools or formats (or maybe a textual "interface" format too as domain-specific language that's tailored for allowing people to edit the pattern files, either semantical itself or interpreted + converted to a semantic format for further processing) which make sure that the semantic meaning and structure of pattern files is stated explicitly and therefore can be processed/converted more easily.

Shouldn't be too difficult, just takes a little while to set up, maybe as a parallel experiment/prototype.