No edit summary |
(→Statistic about the distribution itself: new section) |
||
Line 23: | Line 23: | ||
:And just so you know — it never feels like time is linear ;) --[[User:Ianweller|Ian Weller]] 01:22, 18 June 2009 (UTC) | :And just so you know — it never feels like time is linear ;) --[[User:Ianweller|Ian Weller]] 01:22, 18 June 2009 (UTC) | ||
== Statistic about the distribution itself == | |||
I don't know if this really is in alignment with this effort but there are some metrics that could be used to monitor the "health" and development of the distribution or various parts of it: | |||
* # of packages in comps and the comps groups | |||
** I have a bar graph in mind with the bar representing all packages and the groups are coloured parts showing the relative size. | |||
* amount of content in the packages by file type | |||
** I have a script for the stats on [[Features/NoarchSubpackages]]. It could probably be extended to more fine grained categorization of the package contents. | |||
** don't know whether this really makes sense | |||
** automatically generating the noarch stats would of course be a big help for the Feature | |||
* Connectivity of the dependency graph. We often have the problem that by accident packages requiring packages that they really shouldn't (like large part of gnome by fedora-release). The question is whether we can calculate a number for the distribution or each package that makes such changes detectable. Such metric could also be used further thin out the dependencies throughout the distribution. May be mixing this with the comps information can make it easier to find the interesting packages. | |||
* # number of packages with common post fix. There are a few very common postfixes in the package names: -devel, -doc, -data, -common. Knowing the numbers could give a better impression how the distribution looks like. | |||
--[[User:Ffesti|Ffesti]] 10:04, 18 June 2009 (UTC) |
Revision as of 10:04, 18 June 2009
Please use the "+" button at the top of the page to add your potential use case. This will split each one into a section so that discussion can follow.
Sign your comments with --~~~~!
Jsmidt's suggestion
Sorry to list what seems like "everything" but I believe these statistics are all important to various groups of people. As for use cases, each of these could be important for marketing: "Look we fixes a high percentage of bugs", "We have lots of new packages coming in", "Documentation is really improving", etc... Furthermore, each thing I list helps establish the health of the project in each area. "Are we doing enough to encourage translators to contribute", "Are we fixing bugs well", etc...
- Number of people joining the project as a function of time
- Number of Ambassadors as function of time
- Number of translators as function of time
- Number of BugZappers as function of time
- Number of packagers as function of time
- Number of people on docs team as function of time
- Number of designers as function of time
- Numbers if wiki edits as function of time
- Number of packages in Fedora as function of time
- Number of people using Fedora as a function of time.
- Number of bugs opened each week as a function of time
- Number of bugs closed each week as a function of time
- Function of time as a function of time. (Better be linear).
--Jsmidt 01:16, 18 June 2009 (UTC)
- Thanks for the wonderful suggestions, I'll get these integrated into the main use cases page shortly.
- And just so you know — it never feels like time is linear ;) --Ian Weller 01:22, 18 June 2009 (UTC)
Statistic about the distribution itself
I don't know if this really is in alignment with this effort but there are some metrics that could be used to monitor the "health" and development of the distribution or various parts of it:
- # of packages in comps and the comps groups
- I have a bar graph in mind with the bar representing all packages and the groups are coloured parts showing the relative size.
- amount of content in the packages by file type
- I have a script for the stats on Features/NoarchSubpackages. It could probably be extended to more fine grained categorization of the package contents.
- don't know whether this really makes sense
- automatically generating the noarch stats would of course be a big help for the Feature
- Connectivity of the dependency graph. We often have the problem that by accident packages requiring packages that they really shouldn't (like large part of gnome by fedora-release). The question is whether we can calculate a number for the distribution or each package that makes such changes detectable. Such metric could also be used further thin out the dependencies throughout the distribution. May be mixing this with the comps information can make it easier to find the interesting packages.
- # number of packages with common post fix. There are a few very common postfixes in the package names: -devel, -doc, -data, -common. Knowing the numbers could give a better impression how the distribution looks like.
--Ffesti 10:04, 18 June 2009 (UTC)