search

fabric8io / fabric8

fabric8 is an open source microservices platform based on Docker, Kubernetes and Jenkins
http://fabric8.io/
1.76k stars 504 forks source link

add a standup/team status bot #4383

Open jstrachan opened 9 years ago

jstrachan commented 9 years ago

as described here... https://medium.com/why-not/what-will-the-automated-workplace-look-like-495f9d1e87da

great way to do automated status reports for teams etc

christian-posta commented 9 years ago

this is pretty interesting.. i'm partial to and have used this approach approach a lot in the past (and currently) http://blog.idonethis.com/google-snippets-internal-tool/ wonder if slack can do something similar (think it can), or if there's another opensource project that we could integrate. this would be a crucial part to the "culture" equation of microservices where the org is a little more flat, self/peer managing, and of smaller teams

On Thu, Jul 2, 2015 at 5:45 AM, James Strachan notifications@github.com wrote:

as described here...

https://medium.com/why-not/what-will-the-automated-workplace-look-like-495f9d1e87da

great way to do automated status reports for teams etc

— Reply to this email directly or view it on GitHub https://github.com/fabric8io/fabric8/issues/4383.

Christian Posta twitter: @christianposta http://www.christianposta.com/blog http://fabric8.io

jimmidyson commented 9 years ago

While Slack is undoubtedly awesome, we do have to ensure there is an open source alternative IMO as @christian-posta mentioned. Otherwise we're at risk of creating something brilliant but community being put off due to cost, etc. Has anything been looked at yet?

jstrachan commented 9 years ago

Agreed. I was assuming us reusing/writing an OSS hubot bot that works with all chat back ends (IRC / letschat / slack et al)

rawlingsj commented 9 years ago

yeah so we have all the building blocks in place already with hubot and lets chat, they work great now and easily extendable for exactly this type of usecase.

rawlingsj commented 9 years ago

here's the hubot scripts repo https://github.com/fabric8io/fabric8-hubot-scripts

I've actually just refactored the three hubot implementations we use for slack, lets chat and irc to use a common base image that pulls the scripts in when the images are built. I'll push them shortly.

jstrachan commented 9 years ago

this one might be worth a try: https://www.npmjs.com/package/hubot-standup

I wonder if we could associate chat rooms with projects; so that we can use the team page the project's issue tracker to auto-create the teams? (though I guess we'd need to know folks chat handles too)

cmoulliard commented 9 years ago

That could interesting that we support within the yaml config file the team's setup. We could reuse this feature also to create the list of users assigned to Gerrit project process

team:

where pm = project manager and user(n) : First Name, Last Name, Account & Email of the user (example : Charles, Moulliard, cmoulliard, ch007m@gmail.com)

On Thu, Jul 2, 2015 at 8:52 PM, James Strachan notifications@github.com wrote:

this one might be worth a try: https://www.npmjs.com/package/hubot-standup

I wonder if we could associate chat rooms with projects; so that we can use the team page the project's issue tracker to auto-create the teams? (though I guess we'd need to know folks chat handles too)

— Reply to this email directly or view it on GitHub https://github.com/fabric8io/fabric8/issues/4383#issuecomment-118125659.

Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io

jstrachan commented 9 years ago

we want to avoid maintaining multiple team lists; as its extra maintenance for teams. So I'd prefer we default to reusing either the issue tracker or git hosting for maintaining the team list. Right now the UI defaults to the Team page of the issue tracker as the canonical list of the team members

cmoulliard commented 9 years ago

Nevertheless, we offer the possibility with gerrit ( https://github.com/fabric8io/quickstarts/blob/master/apps/gerrit/src/main/fabric8/env.properties#L19) to define such a list of users. That should not be an extra work to read it from the yaml config file in order to parameterise next the kube app using the templateParameter ?

On Mon, Jul 6, 2015 at 9:25 AM, James Strachan notifications@github.com wrote:

we want to avoid maintaining multiple team lists; as its extra maintenance for teams. So I'd prefer we default to reusing either the issue tracker or git hosting for maintaining the team list. Right now the UI defaults to the Team page of the issue tracker as the canonical list of the team members

— Reply to this email directly or view it on GitHub https://github.com/fabric8io/fabric8/issues/4383#issuecomment-118754119.

Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io

jstrachan commented 9 years ago

I'd rather we look at the bigger picture and the user. Do we really want them maintaining by hand a yaml file for team members just for gerrit and for gogs and taiga too? Why not just populate gerrit from the taiga team for example

christian-posta commented 9 years ago

On Mon, Jul 6, 2015 at 12:34 AM, James Strachan notifications@github.com wrote:

I'd rather we look at the bigger picture and the user. Do we really want them maintaining by hand a yaml file for team members just for gerrit and for gogs and taiga too? Why not just populate gerrit from the taiga team for example

We don't want to do that. Sounds like a pain to try to track fine-grained group membership inside projects. SCM tool and its groups/permissions should be sufficient, right?

— Reply to this email directly or view it on GitHub https://github.com/fabric8io/fabric8/issues/4383#issuecomment-118756892.

Christian Posta twitter: @christianposta http://www.christianposta.com/blog http://fabric8.io

jstrachan commented 9 years ago

@christian-posta agreed - either the SCM or the issue tracker should be considered the master for teams; they all have a nice UI to add/edit/view teams too. e.g. we default to the Taiga team page by default right now if folks use Taiga.

cmoulliard commented 9 years ago

You are right. We will keep separate the users part of a team in charge to handle the stuffs concerning SCM (that we can easily manage using the different web console) from the technical users accounts required to interconnect jenkins with gerrit, gogs with gerrit, ... For these technical accounts, we should offer the possibility to parameterize them using the yaml config file nevertheless ...

On Mon, Jul 6, 2015 at 4:15 PM, James Strachan notifications@github.com wrote:

@christian-posta https://github.com/christian-posta agreed - either the SCM or the issue tracker should be considered the master for teams; they all have a nice UI to add/edit/view teams too. e.g. we default to the Taiga team page by default right now if folks use Taiga.

— Reply to this email directly or view it on GitHub https://github.com/fabric8io/fabric8/issues/4383#issuecomment-118869087.

Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io