Implement project updates as fixed part of kanthaus

It was discussed offline for a while how the personal projects update meetings could be improved. The goal seems to be generally to put more focus on the projects happening here and how newcomers can get into them.

Some ideas how it could be:

• Monthly, should be scheduled way in advance (maybe 2 weeks in advance) so people can prepare and plan to attend
• create and update posters in the entrance about what Volunteers and Members are doing here and how one can participate
• update kanthaus homepage to show information about projects publicly
• participation at the meeting is expected from Volunteers and Members, if you can't you should participate asynchronously (for example, prepare the updated poster)
• make it a part of collective agreements

changed title from Implement projects as fixed part of kanthaus to Implement project updates as fixed part of kanthaus

i like the general idea, as long as its voluntarily

this reminds me of the yunity heartbeat, maybe there is potential for combining these ideas somwhow?

If we include the projects as data somewhere, and then we could also maybe keep track of project updates, and spam some slack channels with what people are working on, etc....

assigned to @tiltec

changed milestone to %Winter 2018/19

Talked about it with @nicksellen and @DougInAMug

It could be good to collect project updates asynchronously, e.g. by weekly email to project maintainers. The reply would be posted in a Slack channel and every month, maintainers would compile a succinct summary and present it at the project update meeting. This could be posted to the website and printed to the K20 entrance (@djahnie likes to have that too). Idea is: weekly updates are somehow internal, whereas monthly summaries are intended as public report.

I'm thinking a slack bot that opens up a private chat with each person that has "a project", and it spams them with reminders to write an update, you then just type stuff into that chat and it gets collected and aggregated.

More specifically, maybe the journey goes something like:

• person joins slack in #kanthaus channel
• someone tells them about #kanthaus-projects channel
• they join
• each week (or day? or month?) it goes through the members of that channel and writes a private message to each of them asking them what they've been up to (with a time limited range, 1 day?)
• the person writes one or more messages about the project
• the bot reads the messages and saves them somewhere
• maybe the next day it posts them internally (in the #kanthaus-projects channel?)
• (if somebody doesn't write updates for a while, it kicks them out?)

A few questions/unthought things:

• does it implement something that would actually solve the needs?
• what if someone has multiple projects?
• is it only for people in the house? or also remote?
• how to address the more general public facing summaries?
• where does it save the updates? (in git? on yuca?)
• where would it run? (yuca? gitlab ci?)
• as @spaceywolfi wondered, can it be reused for the heartbeat

Other ideas:

• define projects + slack usernames in a yaml file in kanthaus private (instead of using #kanthaus-projects members)
• reuse the kanthaus website project listing + people (DRY)
• reuse the infrastructure to compile the heartbeat :) (basically reimplementing @djahnie in python)

assigned to @DougInAMug

Hello @nicksellen @tiltec

I'm just going through my roadmap commitments and realized I'm assigned here. I'm interested in the topic. Meta: there is no DoD, which is OK, but then we might wint to prefix this as Epic:

The discussion we (nick, me, taïs, janina, clara) had was nice and seemed to overlap here.

@djahnie and I chatted a bit about this. In our experience trying to organize project updates and roadmap events in the same week is too much. We could:

• have 4 personal updates, equally spaced between the roadmaps (we could then align with the pagan wheel of the year! https://en.wikipedia.org/wiki/Wheel_of_the_Year#/media/File:Phases_of_the_Sun_(NHemi).png )
• have 8 personal updates, equally spaced between the roadmaps (i.e. roadmap/personal update once per month
• have 12 personal updates, one in the middle of every month.

I strongly prefer any of these options to the current clash we have, and significantly prefer the first and second to the third.

(Also, djahnie: I get a bit confused with different, pseudonymous handles on different platforms. Presents findability for newbies.)

I am a bit sad the interest in the async workflow seemed to go away, but hey ho. I would not pursue it further.

changed milestone to %Spring 2019

I'll try to work on the bot in the Spring 2019 roadmap, with input from @ClaraThomps.

I would make a bot that asks people in Kanthaus Slack "What would you like to share with others?" every Friday or so. Then it waits until Sunday and compiles all responses into a nice report.

• each response could have a category, e.g. what project it is about. then the bot can compile per-category reports, and readers can select what they are interested in
• sharing pictures would be great
• ready to receive responses all the time, to allow fully async workflows
• can people collaborate to write a response?

Also: should I make this into a separate issue?

I think an advantage of the bot will be that it could integrate visitors more easily into Kanthaus and enable a larger scale skillshare! There could be a wider range of questions the bot asks. Besides "What is it your currently working on?" we could also ask "Is there something you currently need help with/people can help you with?" and then maybe tag a category (like "creative", "renovating", "writing"). So when reviewing the current projects at Kanthaus people can filter the projects that match their own skills. The question "what would you like to share with others?" that Tillman proposed I also like because visitors who are here without a fixed project can also share things they are interested in or would like to start working on.

I'm thinking about it again and again, but I can't imagine how the system would work. That makes it hard to implement something. Hence I'm going to remove myself from the issue and see how others would tackle this.

unassigned @tiltec

Think @djahnie is on this? Unassigning myself

unassigned @DougInAMug