2009/3/31 Wojtek Walczak <gminick(a)tosh.pl>:
Michael DeHaan napisal(a):
Michael,
> For instance, what users talk to what users is probably not something we
> can act on ... but knowing things about the overall
> pulse of different communities is.
I actually think that the data provided by the addition I would like
to create can give a lot of easy understandable and comparable data
that you can act on.
The divisions I made and the statistics I proposed are measuring the
key properties of the communities. And if one knows these properties,
one can act to improve them. Examples:
If the level of exclusiveness is to high it means that the project
associated with the mailing list is going to die in the long perspective
because there is no fresh blood. Thus, the thing developers should
be informed about: invite somebody to your development process,
speak with other people, answer their needs and so on.
If the level of participation of temporary members is high,
go and check it - it means that there are some new, interesting
people who want to contribute. Don't let them go!
If the level of responsiveness is small, let the core developers
and regular users know about it, tell them, that they should spend
more time speaking to the temporary members, because it seems that
they flew too high from what users need.
(I think that responsiveness level should be counted like:
(CTS+RTS) / (CCS+TTS+RRS+CTS+CRS+RTS)
and not:
CTS / (CCS+TTS+RRS+CTS+CRS+RTS)
)
With this tool you can easily assess if the community is "healthy".
If you lack temporary users then something is bad: there is no new
comers. It's not a good prognosis for an open source project.
If there's no real core members group then it's harder to create
the roadmaps, to decide which way to go and so on. Steps should
be taken to create the (hard)core group of coders.
This tool won't be used to define if a community is healthy or not.
Research is not yet at the cause-and-effect stage of analysis. First
we need to draw correlations between different traits of mailing lists
and other data sources between our known qualities of each community,
as well as comparing each community to each other.
There are other aspects we can't analyze simply on this data alone such as:
* Status of the community: is the project stable? in development?
obsolete? passive bug fixes only?
* What is the target demographic and market of the project? Home
users? Enterprise? Hobbyists? Grandma and Grandpa?
* Who is funding and supporting the community? Is this a JBoss
project? Did it start on Launchpad and migrate to FedoraHosted?
* etc...
Once we start acting on the data, we're going to look at it for the
change, and define cause and effect from that stage. It could be a
year before we can consider doing this ;). Let's focus on the first
step.
I really think that my proposition may produce a lot of important data
from your perspective, and that this data is applicable in such sense
that you can act basing on the results. Moreover, the results are really
easily understandable. Minimum and maximum values clearly set, and their
meaning is also easily explainable. Easiness of comparisions also comes
to mind. You can sort the mailing lists by these numbers and look at the
corner cases, without browsing it all.
I think that graphs aren't so much important, but that's the way world
is: you are in pictures or you doesn't exist. You won't even make it
to Slashdot without pictures ;-) Thus, while working on my
proposition I was keeping in mind how to show my statistics on graphs.
They are and they are not. The analysis needs to be seperated from the
graphs, of course, so the data can be manipulated and transmitted to
various targets, but some people, myself included, need to see
something visual and 2d to make the necessary conclusions.
Also, i want to add, most importantly is not just these analysises,
but the relation between different groups. Please make sure to give
yourself time to devote to that sort of analysis too.
-Yaakov