Re: What do we want from Kibble?

[Gavin McDonald]

How about some fine grained control over what metric people/projects want to 
collect and display?

Supposing Kibble collects data on 100 different metrics , how about you do not 
turn on and collect and display all 100, but rather a common subset, the rest 
can be turned on/off at will.

Obviously the’100’ metrics should be configurable in terms of what data is 
searched for and collected, in addition to what is displayed.
  To expand the previous sentence - if someone fine tunes a metric to only 
display last last n posts by people alb,c from list X, then perhaps make it so 
that only that data asked for is collected. (rather than fetch 1000 posts when 
only 6 are required for display)

Gav…

> On 22 Oct 2017, at 5:54 am, Daniel Gruno  wrote:
> 
> 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 
>> 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.
>>> 
>>> 
>>> 
>> 
> 

Re: What do we want from Kibble?

[Daniel Gruno]

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 
> 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.
>>
>>
>>
> 

Re: What do we want from Kibble?

[Rich Bowen]

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 
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.
>
>
>

What do we want from Kibble?

[Daniel Gruno]

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.