search

bugflow / bugflow-docs

documentation for bugflow
0 stars 0 forks source link

daily standup (SUP) plugin #2

Open monkeypants opened 7 years ago

monkeypants commented 7 years ago

It would be great if there was a bugflow module that supported a kind of distributed/asynchronous team daily standup. This ticket is an epic for further analysis.

The overall vision here is for:

Goals/Success:

how this might work

Three bugflow components:

Reference and extrinsic data

These share the same DB model, of the "developers and teams" domain (maintained either with an admin tool or sourced externally):

There is also a concept of an HR worker, who has a HR repo (config data). There is some kind of relationship between these HR workers and the Admin.Client reference data. The HR tasks are raised/tagged by the plugin in the appropriate HR repo.

Automated tasks

Periodic/scheduled celery job: generate SUPs (and nag, if required)

For each client:
    for each distinct developer in any team from any org the client owns:
        if this dev has a SUP report due (e.g. 6am local time):
            if SUP does not exist in DB:
                create empty SUP in the DB
            else if SUP is empty and nag is overdue (e.g. 9.30 am local time)
                task the chatops component to nag the developer about the SUP

As a result, every developer get's SUP created (and nagged about it, if required) once per day for each client that they are working for.

Periodic/scheduled celery job:

For each client:
    find the HR worker + repo for the client
    for all unreviewed submitted SUPs for this client which have not yet been nagged in slack
        nag the HR person in slack to check the unreviewed SUP
    for all unreviewed submitted SUPs for this client which are overdue:
        raise overdue SUP review ticket and assign to HR person

UI

All users:

Pages exist for developers to:

(from SUP detail page can navigate to developer, client, previous/next SUP)

Pages exist for the HR worker to navigate to SUPs multiple ways:

Note: the HR worker has additional fields on a SUP that they can view/edit (HR notes, flags, etc). These are only visible to management and HR staff.

The HR worker must review every SUP and mark it as reviewed.

Basically, the SUP review process is to:

On the page to submit an open SUP, the developer sees:

Since my last SUP (date time):
    * what I said last time was ... (last SUP's 'comment about "by next business day"')
    < for each repo in the client's orgs >
        * list of tickets opened/closed/commented
        * PR's opened/merged
           * summary of commits to PR
        * commits not associated with a PR
        * [optional] comment about work in this repo

By next business day:
    < for each repo in the client's orgs >
        * chose from opened tickets assigned to me
            * expect it to be Done (T/F) ? 
    * scheduling: full day / part day / emergency only / unavailable
    * mandatory comment about "by next business day..."

Issues/Blockers:
  * optional comment about blockers

The idea of the "Since my last SUP" section is to make visible to them their digital footprint since yesterday. If they don't like it, they must update source systems (groom tickets, time accounting, push commits, etc). When the SUP is saved, those things will be snapshotted into a json field on the SUP, and tomorrow's SUP will use "since last SUP submitted" date (not created date), so done things only get counted once.

The idea of "by next business day" is for the developer to express what they intend to do. If they don't know what to put here, they should talk to their delivery manager or team leader. Because of this work, everyone should always know what everyone else plans to work on today, with some idea of how much they plan to work.

if not-null, the blockers all get escalated to the delivery manager for action.

monkeypants commented 7 years ago

Obviously, this should be migrated to auto-gnome and botty-mcbotface.

Specifically, the botty-mcbotface does the work (with dialogs, errobt plugins, DRF etc), and auto-gnome configures him to do so (based on something like DevelopersShouldBeRoutinelyInterrogatedByRobotScrummaster opinion)