Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-12 Thread Jeremy Stanley 
On 2017-06-12 14:07:51 -0700 (-0700), Ken'ichi Ohmichi wrote:
[...]
> The difference between current stackalytics config and the above API
> is stackalytics contains gerrit-id and launchpad-id on the config
> but the API doesn't. I guess we can use e-mail address instead of
> gerrit-id and launchpad-id and hope them from stackalytics config.
[...]

Right, I expect a sane design to be using E-mail addresses to
identify the mapping between the foundation's data, Gerrit and
Launchpad (this would also make it possible to correlate mailing
list posts if we wanted). Something along the lines of querying
Gerrit for the list of known E-mail addresses and then querying the
foundation directory for any profiles associated with each of those
addresses, building up a set of unique foundation IDs as it goes.

Once authentication for Gerrit moves to OpenStackID we can more
directly correlate Gerrit users and foundation profiles based on a
common OpenID.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-12 Thread Ken'ichi Ohmichi 
2017-06-08 10:51 GMT-07:00 Jeremy Stanley :
> On 2017-06-08 09:49:03 -0700 (-0700), Ken'ichi Ohmichi wrote:
>> 2017-06-08 7:19 GMT-07:00 Jeremy Stanley :
> [...]
>> > There is a foundation member directory API now which provides
>> > affiliation details and history, so if it were my project (it's
>> > not though) I'd switch to querying that and delete all the
>> > static affiliation mapping out of that config instead. Not only
>> > would it significantly reduce the reviewer load for
>> > Stackalytics, but it would also provide a greater incentive for
>> > contributors to keep their affiliation data updated in the
>> > foundation member directory.
>>
>> Interesting idea, thanks. It would be nice to centralize such
>> information into a single place. Can I know the detail of the API?
>> I'd like to take a look for some prototyping.
>
> It only _just_ rolled to production at
> https://openstackid-resources.openstack.org/api/public/v1/members
> yesterday so I don't know how stable it should be considered at this
> particular moment. The implementation is at
>  https://git.openstack.org/cgit/openstack-infra/openstackid-resources/tree/app/Models/Foundation/Main/Member.php
>  >
> but details haven't been added to the API documentation in that repo
> yet. (I also just now realized we haven't added a publishing job for
> those API docs either, so I'm working on that bit immediately.)
>
> The relevant GET parameters for this case are
> filter=email==someb...@example.com and relations=all_affiliations
> which gets you a list under the "affiliations" key with all
> start/end dates and organizations for the member associated with
> that address. This of course presumes contributors update their
> foundation profiles to include any E-mail addresses they use with
> Git, as well as recording appropriate affiliation timeframes. Those
> fields in the member directory profiles have existed for quite a few
> years now, so hopefully at least some of us have already done that.

Thanks for the info, Jeremy.

The difference between current stackalytics config and the above API
is stackalytics contains gerrit-id and launchpad-id on the config but
the API doesn't.
I guess we can use e-mail address instead of gerrit-id and
launchpad-id and hope them from stackalytics config.
I will dig more deeply anyways.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-11 Thread Dmitry Tantsur 

On 06/11/2017 03:17 PM, Matt Riedemann wrote:

On 6/8/2017 12:57 AM, Adam Harwell wrote:
As a core reviewer for LBaaS I actually find Stackalytics quite helpful for 
giving me a quick snapshot of contributions, and it lines up almost perfectly 
in my experience with what I see when I'm actually reviewing and working with 
people (if you know which statistics to look at -- just sorting by sheer 
number of reviews or commits and ignoring everything else is of course not 
useful, and as you say possibly misleading). In all though I actually find 
that it is a very accurate representation of people's work.


For example, in looking at reviewer contributions, I make a mental score based 
on both the number of reviews, but also the +% (this shouldn't be too high) 
and the disagreement score (low is generally good, but 0% with a high review 
count might be questionable). So, I know to discount someone who just spams +1 
at everything that has a +2 already and doesn't contribute anything else, 
which can go unnoticed while reading reviews but sticks out like a sore thumb 
in Stackalytics. The other side of the coin is someone who posts a ton of 
useless comments and -1's everything, which then is super obvious to anyone 
who actually reads reviews.


Maybe the experience with the projects I work on is a little different than 
some of the more populous "base" services like Nova or Neutron? Regardless, 
I'd be really sad to see it go, as I use it multiple times a week for various 
reasons. So, I definitely agree with keeping it around and possibly focusing 
on improving the way the data is displayed. It is definitely best used as one 
tool in a toolkit, not taken alone as a single source of truth. Is that the 
main problem people are trying to solve?




I agree with you, and the experience in Nova is the same. I use Stackalytics the 
same way.


Note, however, that reviewstats is also published from a site that russellb has 
running, e.g.:


http://russellbryant.net/openstack-stats/nova-reviewers-30.txt



I sometimes use Stackalytics to get a list of person's latest reviews (e.g. [1]) 
or limit to to a certain project (e.g. [2]). There is something called 
"Person-day effort" (e.g. [3]), which looks also interesting, but I haven't 
looked into it.


[1] http://stackalytics.com/?user_id=divius
[2] http://stackalytics.com/?user_id=divius=ironic-group
[3] 
http://stackalytics.com/?user_id=divius=ironic-group=person-day

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-11 Thread Matt Riedemann 

On 6/8/2017 12:57 AM, Adam Harwell wrote:
As a core reviewer for LBaaS I actually find Stackalytics quite helpful 
for giving me a quick snapshot of contributions, and it lines up almost 
perfectly in my experience with what I see when I'm actually reviewing 
and working with people (if you know which statistics to look at -- just 
sorting by sheer number of reviews or commits and ignoring everything 
else is of course not useful, and as you say possibly misleading). In 
all though I actually find that it is a very accurate representation of 
people's work.


For example, in looking at reviewer contributions, I make a mental score 
based on both the number of reviews, but also the +% (this shouldn't be 
too high) and the disagreement score (low is generally good, but 0% with 
a high review count might be questionable). So, I know to discount 
someone who just spams +1 at everything that has a +2 already and 
doesn't contribute anything else, which can go unnoticed while reading 
reviews but sticks out like a sore thumb in Stackalytics. The other side 
of the coin is someone who posts a ton of useless comments and -1's 
everything, which then is super obvious to anyone who actually reads 
reviews.


Maybe the experience with the projects I work on is a little different 
than some of the more populous "base" services like Nova or Neutron? 
Regardless, I'd be really sad to see it go, as I use it multiple times a 
week for various reasons. So, I definitely agree with keeping it around 
and possibly focusing on improving the way the data is displayed. It is 
definitely best used as one tool in a toolkit, not taken alone as a 
single source of truth. Is that the main problem people are trying to solve?




I agree with you, and the experience in Nova is the same. I use 
Stackalytics the same way.


Note, however, that reviewstats is also published from a site that 
russellb has running, e.g.:


http://russellbryant.net/openstack-stats/nova-reviewers-30.txt

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-09 Thread Mike Perez 
On June 8, 2017 at 07:20:23, Jeremy Stanley (fu...@yuggoth.org) wrote:
> > On 2017-06-07 16:36:45 
> > -0700(http://airmail.calendar/2017-06-07%2016:36:45%20PDT)
> (-0700), Ken'ichi Ohmichi wrote:
> [...]
> > one of config files is 30KL due to much user information and that
> > makes the maintenance hard now. I am trying to separate user
> part
> > from the existing file but I cannot find the way to make a
> > consensus for such thing.
>
> There is a foundation member directory API now which provides
> affiliation details and history, so if it were my project (it's
> not
> though) I'd switch to querying that and delete all the static
> affiliation mapping out of that config instead. Not only would
> it
> significantly reduce the reviewer load for Stackalytics, but
> it
> would also provide a greater incentive for contributors to keep
> their affiliation data updated in the foundation member directory.

+1. This would really help me when generating the stats for our yearly
reports/keynote/etc stats instead of having to query multiple sources
and figure out which one is more current.

—
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-08 Thread Jeremy Stanley 
On 2017-06-08 09:49:03 -0700 (-0700), Ken'ichi Ohmichi wrote:
> 2017-06-08 7:19 GMT-07:00 Jeremy Stanley :
[...]
> > There is a foundation member directory API now which provides
> > affiliation details and history, so if it were my project (it's
> > not though) I'd switch to querying that and delete all the
> > static affiliation mapping out of that config instead. Not only
> > would it significantly reduce the reviewer load for
> > Stackalytics, but it would also provide a greater incentive for
> > contributors to keep their affiliation data updated in the
> > foundation member directory.
> 
> Interesting idea, thanks. It would be nice to centralize such
> information into a single place. Can I know the detail of the API?
> I'd like to take a look for some prototyping.

It only _just_ rolled to production at
https://openstackid-resources.openstack.org/api/public/v1/members
yesterday so I don't know how stable it should be considered at this
particular moment. The implementation is at
https://git.openstack.org/cgit/openstack-infra/openstackid-resources/tree/app/Models/Foundation/Main/Member.php
 >
but details haven't been added to the API documentation in that repo
yet. (I also just now realized we haven't added a publishing job for
those API docs either, so I'm working on that bit immediately.)

The relevant GET parameters for this case are
filter=email==someb...@example.com and relations=all_affiliations
which gets you a list under the "affiliations" key with all
start/end dates and organizations for the member associated with
that address. This of course presumes contributors update their
foundation profiles to include any E-mail addresses they use with
Git, as well as recording appropriate affiliation timeframes. Those
fields in the member directory profiles have existed for quite a few
years now, so hopefully at least some of us have already done that.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-08 Thread Ken'ichi Ohmichi 
2017-06-08 7:19 GMT-07:00 Jeremy Stanley :
> On 2017-06-07 16:36:45 -0700 (-0700), Ken'ichi Ohmichi wrote:
> [...]
>> one of config files is 30KL due to much user information and that
>> makes the maintenance hard now. I am trying to separate user part
>> from the existing file but I cannot find the way to make a
>> consensus for such thing.
>
> There is a foundation member directory API now which provides
> affiliation details and history, so if it were my project (it's not
> though) I'd switch to querying that and delete all the static
> affiliation mapping out of that config instead. Not only would it
> significantly reduce the reviewer load for Stackalytics, but it
> would also provide a greater incentive for contributors to keep
> their affiliation data updated in the foundation member directory.

Interesting idea, thanks.
It would be nice to centralize such information into a single place.
Can I know the detail of the API? I'd like to take a look for some prototyping.

>> In addition, we have two ways for managing bug reports: launchpad and
>> storyboard if considering it as infra project.
>
> It's not (at least presently) an Infrastructure team deliverable.
> It's only an unofficial project which happens to have granted the
> infra-core team approval rights (for reasons I don't recall, if I
> ever even knew it was the case before now).
>
>> It would be necessary to transport them from launchpad, I guess.
> [...]
>
> If its maintainers want to migrate from LP to SB, we already have an
> import script which copies in all the existing bug reports so that's
> not really a challenge.

Oh, cool. Glad to hear that :)

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-08 Thread Paul Belanger 
On Thu, Jun 08, 2017 at 02:11:18PM +, Jeremy Stanley wrote:
> On 2017-06-08 09:22:48 -0400 (-0400), Paul Belanger wrote:
> [...]
> > We also have another issue where we loose access to gerrit and our apache
> > process pins CPU to 100%, these might also be low hanging friut for people
> > wanting to get involved.
> [...]
> 
> Wasn't that fixed with a new lower-bound on paramiko so it now
> closes SSH API sessions correctly?
>
We did submit a patch, but I believe we are still leaking some connections to
gerrit. We likley need to audit the code to ensure we applied the patch to all
connection attempts.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-08 Thread Jeremy Stanley 
On 2017-06-07 16:36:45 -0700 (-0700), Ken'ichi Ohmichi wrote:
[...]
> one of config files is 30KL due to much user information and that
> makes the maintenance hard now. I am trying to separate user part
> from the existing file but I cannot find the way to make a
> consensus for such thing.

There is a foundation member directory API now which provides
affiliation details and history, so if it were my project (it's not
though) I'd switch to querying that and delete all the static
affiliation mapping out of that config instead. Not only would it
significantly reduce the reviewer load for Stackalytics, but it
would also provide a greater incentive for contributors to keep
their affiliation data updated in the foundation member directory.

> In addition, we have two ways for managing bug reports: launchpad and
> storyboard if considering it as infra project.

It's not (at least presently) an Infrastructure team deliverable.
It's only an unofficial project which happens to have granted the
infra-core team approval rights (for reasons I don't recall, if I
ever even knew it was the case before now).

> It would be necessary to transport them from launchpad, I guess.
[...]

If its maintainers want to migrate from LP to SB, we already have an
import script which copies in all the existing bug reports so that's
not really a challenge.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-08 Thread Jeremy Stanley 
On 2017-06-08 09:22:48 -0400 (-0400), Paul Belanger wrote:
[...]
> We also have another issue where we loose access to gerrit and our apache
> process pins CPU to 100%, these might also be low hanging friut for people
> wanting to get involved.
[...]

Wasn't that fixed with a new lower-bound on paramiko so it now
closes SSH API sessions correctly?
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-08 Thread Paul Belanger 
On Wed, May 17, 2017 at 06:55:57PM +, Jeremy Stanley wrote:
> On 2017-05-17 16:16:30 +0200 (+0200), Thierry Carrez wrote:
> [...]
> > we need help with completing the migration to infra. If interested
> > you can reach out to fungi (Infra team PTL) nor mrmartin (who
> > currently helps with the transition work).
> [...]
> 
> The main blocker for us right now is addressed by an Infra spec
> (Stackalytics is an unofficial project and it's unclear to us where
> design discussions for it happen):
> 
> https://review.openstack.org/434951
> 
> In particular, getting the current Stackalytics developers on-board
> with things like this is where we've been failing to make progress
> mainly (I think) because we don't have a clear venue for discussions
> and they're stretched pretty thin with other work. If we can get
> some additional core reviewers for that project (and maybe even talk
> about turning it into an official team or joining them up as a
> deliverable for an existing team) that might help.
> -- 
> Jeremy Stanley

Agree with Jeremy.

We have been running a shadow instances of stackalytics[1] for 2 years now. So,
we could make the flip today to our community infrastructure if we wanted too.
The persistent cache would be a helpful thing to avoid potential re-imports of
all the data.

We also have another issue where we loose access to gerrit and our apache
process pins CPU to 100%, these might also be low hanging friut for people
wanting to get involved.

[1] http://stackalytics.openstack.org

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-08 Thread Adam Harwell 
I wish I'd made it to that Forum session, but here's my two cents now:

As a core reviewer for LBaaS I actually find Stackalytics quite helpful for
giving me a quick snapshot of contributions, and it lines up almost
perfectly in my experience with what I see when I'm actually reviewing and
working with people (if you know which statistics to look at -- just
sorting by sheer number of reviews or commits and ignoring everything else
is of course not useful, and as you say possibly misleading). In all though
I actually find that it is a very accurate representation of people's work.

For example, in looking at reviewer contributions, I make a mental score
based on both the number of reviews, but also the +% (this shouldn't be too
high) and the disagreement score (low is generally good, but 0% with a high
review count might be questionable). So, I know to discount someone who
just spams +1 at everything that has a +2 already and doesn't contribute
anything else, which can go unnoticed while reading reviews but sticks out
like a sore thumb in Stackalytics. The other side of the coin is someone
who posts a ton of useless comments and -1's everything, which then is
super obvious to anyone who actually reads reviews.

Maybe the experience with the projects I work on is a little different than
some of the more populous "base" services like Nova or Neutron? Regardless,
I'd be really sad to see it go, as I use it multiple times a week for
various reasons. So, I definitely agree with keeping it around and possibly
focusing on improving the way the data is displayed. It is definitely best
used as one tool in a toolkit, not taken alone as a single source of truth.
Is that the main problem people are trying to solve?

   --Adam

On Wed, Jun 7, 2017, 16:38 Ken'ichi Ohmichi  wrote:

> 2017-05-17 11:55 GMT-07:00 Jeremy Stanley :
> > On 2017-05-17 16:16:30 +0200 (+0200), Thierry Carrez wrote:
> > [...]
> >> we need help with completing the migration to infra. If interested
> >> you can reach out to fungi (Infra team PTL) nor mrmartin (who
> >> currently helps with the transition work).
> > [...]
> >
> > The main blocker for us right now is addressed by an Infra spec
> > (Stackalytics is an unofficial project and it's unclear to us where
> > design discussions for it happen):
> >
> > https://review.openstack.org/434951
>
> I also want to find a good design discussion space for stackalytics future.
> For example, one of config files is 30KL due to much user information
> and that makes the maintenance hard now.
> I am trying to separate user part from the existing file but I cannot
> find the way to make a consensus for such thing.
> In addition, we have two ways for managing bug reports: launchpad and
> storyboard if considering it as infra project.
> It would be necessary to transport them from launchpad, I guess.
>
> > In particular, getting the current Stackalytics developers on-board
> > with things like this is where we've been failing to make progress
> > mainly (I think) because we don't have a clear venue for discussions
> > and they're stretched pretty thin with other work. If we can get
> > some additional core reviewers for that project (and maybe even talk
> > about turning it into an official team or joining them up as a
> > deliverable for an existing team) that might help.
>
> Yeah, diversity will be great for our future.
>
> Thanks
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-06-07 Thread Ken'ichi Ohmichi 
2017-05-17 11:55 GMT-07:00 Jeremy Stanley :
> On 2017-05-17 16:16:30 +0200 (+0200), Thierry Carrez wrote:
> [...]
>> we need help with completing the migration to infra. If interested
>> you can reach out to fungi (Infra team PTL) nor mrmartin (who
>> currently helps with the transition work).
> [...]
>
> The main blocker for us right now is addressed by an Infra spec
> (Stackalytics is an unofficial project and it's unclear to us where
> design discussions for it happen):
>
> https://review.openstack.org/434951

I also want to find a good design discussion space for stackalytics future.
For example, one of config files is 30KL due to much user information
and that makes the maintenance hard now.
I am trying to separate user part from the existing file but I cannot
find the way to make a consensus for such thing.
In addition, we have two ways for managing bug reports: launchpad and
storyboard if considering it as infra project.
It would be necessary to transport them from launchpad, I guess.

> In particular, getting the current Stackalytics developers on-board
> with things like this is where we've been failing to make progress
> mainly (I think) because we don't have a clear venue for discussions
> and they're stretched pretty thin with other work. If we can get
> some additional core reviewers for that project (and maybe even talk
> about turning it into an official team or joining them up as a
> deliverable for an existing team) that might help.

Yeah, diversity will be great for our future.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

2017-05-17 Thread Jeremy Stanley 
On 2017-05-17 16:16:30 +0200 (+0200), Thierry Carrez wrote:
[...]
> we need help with completing the migration to infra. If interested
> you can reach out to fungi (Infra team PTL) nor mrmartin (who
> currently helps with the transition work).
[...]

The main blocker for us right now is addressed by an Infra spec
(Stackalytics is an unofficial project and it's unclear to us where
design discussions for it happen):

https://review.openstack.org/434951

In particular, getting the current Stackalytics developers on-board
with things like this is where we've been failing to make progress
mainly (I think) because we don't have a clear venue for discussions
and they're stretched pretty thin with other work. If we can get
some additional core reviewers for that project (and maybe even talk
about turning it into an official team or joining them up as a
deliverable for an existing team) that might help.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [forum] Future of Stackalytics

2017-05-17 Thread Thierry Carrez 
Hi!

Following the forum, the session moderators should summarize how their
session went and detail next steps, to give opportunity to those who
couldn't be around in person to catch up if interested. Here is my quick
summary of the "Should we kill Stackalytics" session. You can find the
etherpad at [1].

After a quick intro on the history of Stackalytics, we spent some time
discussing the issues with the current situation. Beyond limited
maintenance resources, some accuracy issues and partial infra
transition, it became clear in the session that the major driver for a
change is that Stackalytics incentivizes the wrong behavior(s),
especially in new contributors and organizations in their first step of
involvement. As the only "official" and visible way to measure
contribution, it encourages dumping useless patches and reviews, and
does not value strategic contributions over more tactical contributions.
Beyond wasted resources and being annoying to core reviewers, it fails
to drive those new contributors to what could be extremely useful
contributions, and prevents them to step up in the community.

At the same time, several people in the room raised that they would
rather not support solutions that would just "kill Stackalytics". Having
access to raw metrics on project contribution is useful, for various
profiles. It's when you start adding apples to oranges, or deriving
rankings from those compound metrics that things start to go very wrong.
If Stackalytics was just removed, no doubt it would soon be reborn in
other forms elsewhere. Also removing it while not providing anything to
replace it is totally useless.

We need to first provide a clear incentive to work on desirable items
and under-staffed critical teams. The TC is exploring how we could
produce such a "help wanted" list (action driven by myself), together
with how to give proper recognition to the individuals working on that
and/or the organizations funding their work. Once that is done, we'll
likely explore how to remove most of the misleading rankings and graphs
from Stackalytics to focus it on raw metric information. Before we can
do that, we need to complete transition of Stackalytics to OpenStack
infrastructure. Once that work is completed it will be time to
reconsider our options and have a follow-up discussion session.

In summary, the following follow-on work items were identified:

1. Set up the "help wanted" list at TC level and associated hall of fame
(action: ttx and TC members)
2. Complete Stackalytics migration to infra (action: infra team, mrmartin)
3. Explore which are the most misleading information/graphs from
stackalytics that we might want to remove
4. Reconsider the issue once that work is completed

If interested, please jump in! In particular we need help with
completing the migration to infra. If interested you can reach out to
fungi (Infra team PTL) nor mrmartin (who currently helps with the
transition work).

[1] https://etherpad.openstack.org/p/BOS-forum-should-we-kill-stackalytics

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev