I think it's important that we are neutral in terms of saying that a particular metric is important, useful, necessary, so on. That is, while it may be obvious to us that a more corporately-diverse developer pool is a good thing, that is an opinion based in dogma, not in science. What's a "good" value for a particular metric is a matter of philosophy rather than science. What constitutes a healthy community is, also.
The software should be awesome at collecting data and displaying trends. The specific community in question is responsible for interpreting what they mean, in the context of their own community, and what they want to do about it. The question of "here's what you should do to make your community more healthy" is amazingly complicated, and while that may be a goal some day, it's in a much later version. This also implies that we should be asking projects (LOTS of them) what metrics/trends they wish they had a tool to track, and provide those tools. We should also be asking them what correlations they want to see and add those tools. Things like "when I make a release I get more downloads" or "when I add N new committers my tickets get closed slower/faster" or whatever. We don't know what they want to know, and if we assume that we do, we'll be missing an opportunity. On Sat, Oct 21, 2017 at 12:57 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > to me, ideally, Kibble 1.0 would be when it has the features required to > replace Snoot in Apache Projects Statistics [1] (Snoot service could use > Kibble 1.0 as its code) > > Looking at the "Data Points" page in Kibble demo [2], it seems we're not so > far: release early, release often, adding features not available in Snoot > for > projects.a.o would be for next versions > > Regards, > > Hervé > > [1] https://projects.apache.org/statistics.html > > [2] https://demo.kibble.apache.org/dashboard.html?page=repos > > Le vendredi 20 octobre 2017, 16:17:47 CEST Daniel Gruno a écrit : > > I'd like to kick off a larger discussion around what we hope Kibble can > > achieve, and how this will come about. > > > > For starters, what sort of data should we collect and display, what > > types of visualizations should we offer, and are there special formulas > > or algorithms (like Pony Factor) that we'd like to see. Which internal > > features should we be using (such as account linking/collating or > > collapsable groups of repos based on regex etc)? > > > > Then comes the bigger points: At what point would we consider Kibble > > good enough for a release? What things MUST we have before we can go out > > and say "hey, we've got this amazing tool, check it out!"? > > > > On a similar note, I (and probably Rich too) will be reaching out to the > > CHAOSS project over at LF ( http://chaoss.community/ ) to see if we can > > work out some specifications and standards with them, for use in Kibble. > > > > With regards, > > Daniel. > > >
