#204 Packagers group "health script"
Opened a year ago by ankursinha. Modified a year ago

This is strongly linked to #203, but I didn't want to comment there and risk taking focus away from the ticket's goal. This was moved over from the fedora-join ticketing instance: Issue #183


This is an idea I had out of the blue, so please bear with me. It may not be too well fleshed out.

I'm a member of the NeuroFedora SIG, which is basically a bunch of package maintainers that focus on a certain type of software. Now, like every other team, we need more volunteers to help. But, how do we do this? Outreach etc., yes, but first, can we somehow gauge the health of the SIG?

So, the idea is:

  • a python script that that allows us to see metrics for any FAS group (if this is useful, it can be converted to a web-app for the community etc.)

The metrics:

  • total number of members (members, sponsors, administrators: pie chart? XD)
  • total activity over time (over the last week, month, release?): count of total fedmsgs related to this group,
  • average activity over time: total activity/total number of members
  • active members over time: in fedmsgs, number of unique FAS usernames
  • inactive members: (= total - active)
  • new members over time: count of new FAS accounts added to group

This tells us generally what the trend of activity is for the FAS group.

Now, this could maybe used for effort estimation:

  • we could ask group members how much effort (in number of hours per week) does it take for them to do their work,
  • next, we can ask how many hours per week is needed
  • this tells us how many more volunteers are needed for this SIG

This could hopefully help the SIG see their "health", and it could help newcomers (and us in the Join SIG) decide what SIGs are important to join and so on? We will also be able to say that "this group requires X hours of work a week", which will help contributors plan their time out better.

I propose we first start by focussing only on the package-maintainers FAS group simply because everything that happens there tends to emit a fedmsg, and nothing can be done without it being recorded in distinct fedmsg notification types.

If this works, it should be simple enough to include other FAS groups also. It would be nice to include non FAS group teams, but I don't know how that will be done---if they use random projects on pagure etc., we may have to find a mechanism to provide this information when filtering fedmsgs.

Thoughts?


Metadata Update from @bt0dotninja:
- Issue assigned to bt0dotninja

a year ago

I will provide a first approximation asap

Metadata Update from @bt0dotninja:
- Issue priority set to: next meeting (was: awaiting triage)
- Issue tagged with: type - coding, type - metrics

a year ago

Hello everybody,

The stats requested, and other stats will be added/updated here:

https://pagure.io/fedora-commops/FedoraCommunityStats

I will update the first set of stats asap. Still, We will talk about the definition of an active member means, For example, we can quickly know when the last user activity occurs, but this doesn't mean then that event is for some FAS groups, only means then that member is not away from the project.

so give me a few hours to propose an initial solution for the first set of features

Hello everybody,
The stats requested, and other stats will be added/updated here:
https://pagure.io/fedora-commops/FedoraCommunityStats
I will update the first set of stats asap.

Thanks very much.

Still, We will talk about the definition of an active member means, For example, we can quickly know when the last user activity occurs, but this doesn't mean then that event is for some FAS groups, only means then that member is not away from the project.
so give me a few hours to propose an initial solution for the first set of features

For the package maintainer team, activity would be based on package maintaining related tasks. We are narrowing the scope to packaging activities. So, things like:

  • activity on bugzilla (reviewing/new packages/bug fixing)
  • activity on src.fp.o
  • activity on koji
  • activity on bodhi

These are the tools that a package maintainer will necessarily interact with while carrying out their duties. (https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/)

(I'd skip modularity at the minute---I find that it's quite a complex pipeline to understand/analyse currently)

Does that help?

activity on bugzilla (reviewing/new packages/bug fixing)
activity on src.fp.o
activity on koji
activity on bodhi

These are the tools that a package maintainer will necessarily interact with while carrying out their duties. (https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/)
(I'd skip modularity at the minute---I find that it's quite a complex pipeline to understand/analyse currently)
Does that help?

I found this script maybe be help:

https://github.com/pypingou/fedora-active-user

Regards.,

activity on bugzilla (reviewing/new packages/bug fixing)
activity on src.fp.o
activity on koji
activity on bodhi
These are the tools that a package maintainer will necessarily interact with while carrying out their duties. (https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/)
(I'd skip modularity at the minute---I find that it's quite a complex pipeline to understand/analyse currently)
Does that help?

I found this script maybe be help:
https://github.com/pypingou/fedora-active-user
Regards.,

Yes, that's used to report activity for an individual package maintainer (especially when they are inactive). The idea of the this task is a little different. We want to come up with something that gives us metrics over the full population of package maintainers, and not individuals. (something like running this script for each maintainer and then collecting the information to find averages/distributions and so on, but I don't think that would be efficient).

activity on bugzilla (reviewing/new packages/bug fixing)
activity on src.fp.o
activity on koji
activity on bodhi
These are the tools that a package maintainer will necessarily interact with while carrying out their duties. (https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/)
(I'd skip modularity at the minute---I find that it's quite a complex pipeline to understand/analyse currently)
Does that help?
I found this script maybe be help:
https://github.com/pypingou/fedora-active-user
Regards.,

Yes, that's used to report activity for an individual package maintainer (especially when they are inactive). The idea of the this task is a little different. We want to come up with something that gives us metrics over the full population of package maintainers, and not individuals. (something like running this script for each maintainer and then collecting the information to find averages/distributions and so on, but I don't think that would be efficient).

We don't need to worry about efficiency yet; I only want to get the data once and then do the calculations.
Also, we need to define a timeframe, by example,

Active since January 1, 2020, to Now or something like that

activity on bugzilla (reviewing/new packages/bug fixing)
activity on src.fp.o
activity on koji
activity on bodhi
These are the tools that a package maintainer will necessarily interact with while carrying out their duties. (https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/)
(I'd skip modularity at the minute---I find that it's quite a complex pipeline to understand/analyse currently)
Does that help?

I found this script maybe be help:
https://github.com/pypingou/fedora-active-user
Regards.,

Thanks @hhlp I will check it out

Active since January 1, 2020, to Now or something like that

+1 activity will have to be limited to some period. Maybe the past 3/6 months would be sufficient? It just needs to be enough for us to be able to find trends. We can always break down the data once we have it into different windows for further analysis if needed.

Login to comment on this ticket.

Metadata