Github Kanban is a linear process?

[jgeluk]

@jgeluk

You are interpreting Kanban your own unique way and with this you are reinventing the OODA loop.

Look it up.

I have been using and teaching this stuff for 40 years all around the world and I know how it works.

GitHub is just another implementation of Kanban. And now you want still another implementation. Kanban is a linear process.

OODA is a linear process.

Both have decades of research and experienced practitioners. Why would we not want to ride on their coat tails?

Sincerely,

Originally posted by @DennisWisnosky in https://github.com/EKGF/ekg-mm/issues/16#issuecomment-754864156

[jgeluk]

Hi @DennisWisnosky, I tied the above comment that you made originally in issue #16 to this new issue (issue #17) because it is not related to "User Experience" (for the EKG).

I think your comment refers to the 2 versions of "the process" right? For completeness sake I'll upload both versions here:

This is my version:

This is your version:

Both versions are slightly different views on the process. My version is meant for "the collaborator", anyone who wants to make a contribution, providing them with four options:

1. you can be a critic and propose some sort of change or leave feedback as an issue. Which should be a simple as possible with as few conditions as possible. Press that button! Tell us whatever you want. We'll take it from there. Thank you very much for your insight. Job done.
2. you can be a planner which means that you want to invest some time on weekly or bi-weekly phone calls, discussing priorities and content creation efforts etc. That means you have to join a workgroup (i.e. get invited for those phone calls) and work with the corresponding Kanban project board.
3. you can be a fixer who executes whatever is specified in a planned issue.
4. you can be a reviewer / approver who ultimately decides that a given fixed issue gets merged into the final product.

It's as simple as that really. How the actual content is created, I personally don't really care to be honest. You could do it right in the issue itself, see issue #16 for example, or you could do it in Google Docs (and paste the link in the issue) or in Word (and attach that Word doc to the issue). Anything goes. As long as the final content ends up in LaTeX format in this repo which can be done by people like myself, @avaddict , @rivettp, @johnplacek and so forth.

[DennisWisnosky]

I will update my version to include your points We can have two views of the same process. Slack has disappeared from your process and your version of the OODA loop has appeared????

[DennisWisnosky]

I am ok with 2 diagrams, but I have 2 points on the parallel version. 1) Where does your version of the OODA loop fit? 2) I think that your last paragraph above is inconsistent with the diagram. The paragraph says that anybody can participate formally or informally. But the diagrams says that they must be a member of GitHub. I think that we can't have it both ways.

I also sent yo a text message to be sure that all of MA's comments in my diagram are in the collaboration document

[jgeluk]

Everyone who wants to contribute should be a github member yes. If you don't have a github account you can't participate in the discussions or create issues, you'd have to ask someone else to do it then on your behalf. If someone just wants to drop some feedback and mails it to @MikeAtkin or anyone else with an account then that person can create the issue for them but that should be the exception, not the norm.

I had to look up what OODA loop is :-). I wasn't aware that the process diagram was "a version of the OODA loop" and I don't think it was meant to have one, it's just explaining to potential contributors what their options are to contribute to the further development of the EKG/MM, that's all this is. Not meant to be a complete picture of how everything fits together technically. It shows the menu in the restaurant, not the recipe in the kitchen.

[jgeluk]

@DennisWisnosky @jgeluk @avaddict have a look at this updated version of Dennis's diagram, two major changes:

1. Raising issues does NOT require you to join a workgroup
2. Added some "Create Initial Content" steps to make things a bit clearer

What do you think?

EKGMM Process - Dennis Version.pdf