> This is a proposal to begin to end the abuse of the sandbox. (The sandbox
> was intended as a temporary 'play area' for new ideas, not a long term
> project home)
This is a fascinating approach, and not unlike something that drove me
towards Gump in the first place. I was a heavy user of a common (sandbox)
project that after a lot of (user) investment on my part went badly
stagnant. I felt pretty mift, and wished I had some metrics (or similar) to
help me make my choices of dependencies in the first place.
I turned to Gump to attempt to determine which projects were healthy
(stagnant isn't a bad thing for a feature rich, stable product, with a
stable stack below it) and which weren't. I feel it is only 'open' to give
an assessment of a project's status, and what better way that the
'googlesque' (I'm sure it is a word waiting to enter the dictionary ;-)
approach of letting community usage/satisfaction do the talking. Increase
the rating of a project by using it, depending on it. Decrease it by walking
away (as I did) breaking dependency.
Here Gump attempts to 'rate' a project by 'FOG Factor' (eventually something
mystical, a combination of all, but right now a ratio of successes verse
failures, including those of the dependency stack) :
http://lsd.student.utwente.nl/gump/gump_stats/project_fogfactor.html
This is by 'count of dependees' (how many projects depend on the project):
http://lsd.student.utwente.nl/gump/gump_stats/module_dependees.html
This is by last updated (on the module) - yup, sadly bogus for commons, I
know. :(
http://lsd.student.utwente.nl/gump/gump_stats/module_updated.html
Gump is far from done, we'll work with folks to create new views/new stats,
but it is amasing valuable (albethem statistical) insights into projects on
a daily basis.
As such - please do NOT remove these things from Gump, please help us use
Gump to publically determine the wheat from the chaff, whilst you apply PMC
or peer means to clean house of projects that have failed to achieve mass.
Gump might be in a position (especially with help of users like you seeking
solutions) to help you determine what course of action to take for each
component...
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org