Learn more about these different git repos.
Other Git URLs
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:
The metrics:
This tells us generally what the trend of activity is for the FAS group.
Now, this could maybe used for effort estimation:
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?
This is a great idea tbh.This should be a webapp though,with charts or plots. I can take and start the ground work immediately. +1
This is a great idea tbh.This should be a webapp though,with charts or plots. I can take and start the ground work immediately.
I was thinking we'd first prototype to implement the metrics as a proof of concept. When we're sure that it's useful, we can work on the front end. That'll also maybe allow us to have a backend API that people can use to do other things with?
What do you think?
Additional question: does something like this already exist? @alciregi @bt0dotninja @hhlp : any similar scripts/tools that you maybe know of?
This is a great idea tbh.This should be a webapp though,with charts or plots. I can take and start the ground work immediately. I was thinking we'd first prototype to implement the metrics as a proof of concept. When we're sure that it's useful, we can work on the front end. That'll also maybe allow us to have a backend API that people can use to do other things with? What do you think?
I was thinking we'd first prototype to implement the metrics as a proof of concept. When we're sure that it's useful, we can work on the front end. That'll also maybe allow us to have a backend API that people can use to do other things with? What do you think?
Also keep track of telegram,irc and other users.Logging everything to a DB for future analysis accessed via a api.So that all other data can be overlayed on each other aswell and analysed,peak times etc can be found. Yeah making a Backend api first and then simply plugging in the front end would be better. +1 for the api.
should consider Taiga and github projects aswell using their webhooks,api's for proper data analysis. Discussions on Github issues should be considered aswell.
Some time ago I developed a script in order to get some statistics about the QA team. https://pagure.io/qastats (I'm not a developer, nor a data scientist. But it could be useful to get some ideas). Some ideas are based on this other tool developed by @bt0dotninja https://pagure.io/fedora-commops/geofp
Ah, no, see we're already moving towards a large project that "does everything". That's not what I am suggesting:
I am suggesting that first: - we only use users from FAS because all Fedora contributors must have one. - we only use data from fedmsg because that limits our scope to only understanding fedmsg notifications and the datagrepper API.
So, we don't want to start with "everywhere a contributor may be active"---github, gitlab, Telegram, IRC, or Taiga---the effort required to gather these usernames itself tends to be non-trivial, and then learning and using all their individual APIs adds a further layer of complexity that we do not currently have the resources to manage.
So to start with: FAS only, fedmsg only, packager group only. When this is implemented, and we're sure that this is useful to the community, we'll hopefully have more volunteers working on this and then all the other services/APIs can be looked at.
Does that make sense? This is why I'm not even suggesting a finished app. A script that dumps information to the terminal will be quite sufficient to start with.
Those look very nice, and will be excellent references. Especially the second script that uses datagrepper! :clap:
I think commops can suit this ticket; we have a lot of tools than can be updated to get the data and even show it in a better and reasonable manner.
We don't need to reinvent the wheel
Sounds good. I opened a ticket here: https://pagure.io/fedora-commops/issue/204
I saw that 203 was closely linked, but I didn't want to throw in a large comment there.
Metadata Update from @ankursinha: - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)
Cool, thanks
Login to comment on this ticket.