On 10/21/2017 06:11 PM, Rich Bowen wrote: > 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.
Big +1 to this. I think Hervé was more focused on the practicalities here, and I think both aspects are important. We both want something that works and is tangible and accessible, but we also want the more qualitative and anecdotal information out there, not just cold numbers. I know you have a hectic schedule, but it would be awesome if we could come up with some emails to send to the ASF projects for starters, and gauge what they feel are good metrics to keep an eye on as a community - maybe even get some "behind the scenes" commentary on how certain metrics have correlated to ups/downs of various aspects of the projects. Not so we can say "your project is doing well or bad", but so we can provide information on certain metrics and leave it to projects to act based on metrics, information about health/diversity and historical correlations (aka make an informed opinion). With regards, Daniel. > > > On Sat, Oct 21, 2017 at 12:57 PM, Hervé BOUTEMY <[email protected]> > 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. >> >> >> >
