James Carlson wrote: > The reason I mentioned it was in part Jim Grisanzio's passing remark > about consolidations being "only" Sun issues (they're not mere > management; they're important technical details about how the code is > put together), but also because it seems you folks have the whole box > open and are doing internal tinkering on the parts -- something one > hopes doesn't have to happen to often, if only for the sake of the > resulting confusion and angst.
Indeed. Best we shut the lid as soon as possible ;-) > One problem we've had is that we started with an abstract model for > how the web site "should" be used, what the community "should" look > like, and how all the workflows "should" function, and we had the > model well in advance of the actual usage. As a result, we ended up > with a few "does anyone really need this bit?" pieces, and some > confusing "how does that work again?" parts, but also a great deal of > force-fitting: User Groups aren't Projects, but the only scheme we > have to manage them is the Community-Project model, so, by golly, > we'll make that work. We spent similar amounts of time trying to map > bits of ARC machinery into the model (is SAC a community and ARCs are > projects? are members supposed to be core contributors or something > else?), with similar uneven results. I agree. There are several areas that lead to the confusion, one of them is that the terminology used in the current portal application, (e.g. 'Project Editor'). The other is, as you say, that we've munged things together that really should be apart - for example UGs into Projects, and conflating constitutional activities and implementation activities. The proposal that I put forward earlier is based on looking at how things work in practice at present, e.g. noting that some people have commit rights without having a vote. Those two things *may* line up, but in practice they often don't. I'm proposing that we just clean up the anomalies and fudge-arounds in the current system, not that we invent a new structure from scratch. > Having the box open and simplifying what you can is great. I think > the new model, though, should be informed to some extent by the bits > we know we have, rather than going through that mapping process once > again. And thus only really having addressed the User Group problem > and nothing else. A agree, I'm in favour of evolution rather than revolution. I do think however we've done more than just deciding that we need User Groups, for example separating voting from the other bits, removing the Contributor/Core Contributor distinction and so forth. All that is missing is a decision that what we have is sufficient and that I can get on and implement it. -- Alan Burlison --
