On Thursday, Sep 25, 2003, at 16:09 Europe/Rome, Timothy Larson wrote:
I was doing wiring and sleeping during part of this discussion, but please
let me jump in again. We could say something like this about a module:
Code Stability: alpha/beta/final
API/Contract Stability: alpha/beta/final
Support Level: contributed/supported/deprecated
Community Info:
Text writeup plus an Agora-like visual community explorer that includes
info gleaned from the user and dev lists, commits, and downloads.
The text writeup allows more info than just the contributed/supported/deprecated
indicator. It could explain the module's relationship with other modules, and
tell where development is currently headed. For the JXForms/Woody example that
keeps coming up, it could explain that JXForms and Woody are both live, parallel
projects that make different tradeoffs and are attempting to cross-pollinate each
other with good ideas and designs.
My idea is much simpler: the cocoon community defines a workflow for block management and provides a page (which could reside on the URL pointed by the block ID URI) that includes metadata about that block (what it does, who writes it) and the 'community status' [contributed/supported/deprecated]
the format of that page and the metadata that includes are up to the community behind the block.
The Agora-like part would be to give a visual feel of the project's pulse.
No numbers, no numbered scale on graphs, just a visual flow of networks.
well, this is all nice and fancy, but I think you greatly underestimate the effort of doing such datamining and come up with meaningful data that doesn't create frustration and friction.
It would be helpful for it to have a time dimension to see how interest has
swelled over time in relation to the repository commits, and the dev and user
lists. For instance, lots of early activity on the commits and dev list followed
by a slowdown there and a steady increase of related activity on the user list
and downloads (later, when this can be measured by the separate download of blocks)
could indicate the code is maturing and being adopted.
"could" is the key word. statistics (no matter how smart) gives you numbers, how you give those numbers a meaning is a separate concern.
The text writeup above could give clues to help lead to a correct interpretation.
"correct" is the other key word. there is no such thing as "correct interpretation" on the status of the development of a software. Trying to achieve objectivity in such a subjective matter is asking for community trouble.
I only suggest all this because I often find myself wishing for a visual overview
of the different aspects of project activity when I first meet a project.
Me too! Don't get me wrong: I'm continously working on this area (one of my three apachecon presentations will be on 'virtual community dynamics' where I'll present the new version of agora [which I'm currently working on as we speak])
Numbers
do not work for this, because they tell so little of the story. Numbers are one-
dimensional and thereby cannot properly represent the separation of concerns that
a community presents.
Agreed. But agora shows that is hard enough to datamine mail headers (without touching content!). I don't even imagine the complexity of dealing with cross-correlating information from different sources (say mail and CVS or wiki) [not even counting the 'identification' problem which is already hard enough (impossible?) to tackle in email]
Agreed, this whole area of research is potentially very
dangerous and is not absolutely required, so if we skip it for now, that is fine.
that would be my suggestion: while doing research on this direction is a goal I will keep up with, this has nothing to do with cocoon (it's about OSS sociology in general). For sure cocoon might want to use visualization tools, once they are polished and established.... but I wouldn't want to hurt the adoption of blocks (or the friendlyness of the communities behind them) because we used advanced-research sociology tools to promote them.
-- Stefano.
