Open Stack

I agree in that it's dependent on what metrics you think accurately
showcase project health. Is it the number of contributions? The number of
unique contributors? Diversity across participating organizations?
Completion ratios of blueprints or committed fixes over bugs opened? I
imagine different projects will have different opinions on this, but it
would be interesting to know what those opinions are.

I think if you can reasonably justify a metric as an accurate
representation of health, then it makes sense to try and automate it.

This jogged my memory and it might not be a valid metric of health, but I
liked the idea after I heard another project doing it (I think it was
swift). If you could recognize contributions (loosely defined here to be
reviews, patches, bug triage) for an individual and if you noticed those
contributions dropping off after a period of time, then you (as a
maintainer or PTL of a project) could reach out to the individual directly.
This assumes the reason isn't obvious and feels like it is more meant to
track lost contributors.

On Mon, Sep 10, 2018 at 3:27 PM Samuel Cassiba <samuel at cassi.ba> wrote:

> On Mon, Sep 10, 2018 at 6:07 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> > On 2018-09-10 06:38:11 -0600 (-0600), Mohammed Naser wrote:
> >> I think something we should take into consideration is *what* you
> >> consider health because the way we’ve gone about it over health
> >> checks is not something that can become a toolkit because it was
> >> more of question asking, etc
> > [...]
> >
> > I was going to follow up with something similar. It's not as if the
> > TC has a toolkit of any sort at this point to come up with the
> > information we're assembling in the health tracker either. It's
> > built up from interviewing PTLs, reading meeting logs, looking at
> > the changes which merge to teams' various deliverable repositories,
> > asking around as to whether they've missed important deadlines such
> > as release milestones (depending on what release models they
> > follow) or PTL nominations, looking over cycle goals to see how far
> > along they are, and so on. Extremely time-consuming which is why
> > it's taken us most of a release cycle and we still haven't finished
> > a first pass.
> >
> > Assembling some of this information might be automatable if we make
> > adjustments to how the data/processes on which it's based are
> > maintained, but at this point we're not even sure which ones are
> > problem indicators at all and are just trying to provide the
> > clearest picture we can. If we come up with a detailed checklist and
> > some of the checks on that list can be automated in some way, that
> > seems like a good thing. However, the original data should be
> > publicly accessible so I don't see why it needs to be members of the
> > technical committee who write the software to collect that.
> > --
> > Jeremy Stanley
> >
>
> Things like tracking project health I see like organizing a trash
> pickup at the local park, or off the side of a road: dirty,
> unglamorous work. The results can be immediately visible to not only
> those doing the work, but passers-by. Eliminating the human factor in
> deeply human-driven interactions can have ramifications immediately
> noticed.
>
> As distributed as things exist today, reducing the conversation to a
> few methods or people can damage intent, without humans talking to
> humans in a more direct manner.
>
> Best,
> Samuel Cassiba (scas)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180910/2810f0a2/attachment.html>