On Fri, May 04, 2007 at 01:25:53AM -0700, Alan DuBoff wrote: > To be honest, it doesn't say much at all. What is the point in having > Core Contributers and/or Contributers might I ask? Other than voting > rights, it doesn't seem there's much meat to it.
Roy's comments here seem spot on to me. I think you may have different expectations from the rest of ours for what a Community Group is. I'd like to better understand how you're viewing the world here - it may be that the model you have in mind is better than the one we have, but I can't tell what it is. > The device drivers are an intregal part of the kernel. Although the GPL > has never been taken to court, most lawyers seem to be in agreement that ... None of this has anything to do with licensing. Nothing, not even a little teeny tiny bit. > Absolutely shouldn't be a requirement to contribute to the group, but if a > device driver is going back into Solaris, certain standards need to > continue. The current test suites are tough for any driver to pass, and > even some of the drivers that are put back already would fail if run > through some of the test suites again, IMO, but many of them haven't been > tested in years. No one is suggesting that integration requirements have changed. Review, testing, and completeness checks are still in place and we expect them to remain in place, perhaps with minor changes, indefinitely. You seem to think that most (or even all?) of the 43 Community Groups will be responsible for enforcing, and perhaps constructing, those requirements with respect to its area of expertise. Such a system would look nothing like the one we seem to be moving towards - one in which the number of consolidations remains relatively small (a dozen or fewer) with architecturally meaningful boundaries and centralised management. Community Groups, in turn, sponsor projects and act as gatherings of people with related knowledge and interests. Their input needs to be a part of the integration process somehow, but it's unclear what form that will take (though we already have started down this path with project inception). Many Groups have no direct interest in code at all, and the union of all the areas of interest of all existing Groups would not even approach 100% coverage of ON. In most cases, it's unlikely that boundaries can be drawn sufficiently well to allow a single Community Group to make a binding decision - to take a device driver as a seemingly obvious example, shouldn't an author seek the advice of the DTrace Community Group with respect to SDT probe placement and usage? Shouldn't he or she gather input from the Systems Administrators Community Group as to how the driver should be controlled? Our system is highly integrated, and despite a widespread desire for smaller, more focused Community Groups, any successful project team is all but certain to work with more than one. The Constitution implies rather strongly that approving putbacks is a Community Group function, but I'll be damned if I can construct a meaningful Community Group that would be sensibly positioned to make such a call without being entirely inconsistent with the structure of the existing Groups. It may be that we'll end up there anyway, with some Community Groups being more equal than others. > No need to argue, but continue to suggest that investigation for not only > the device driver community, but all communities in general meet some type > of standard in how the contributers are decided, and how many will be We don't actually need to do anything; the Constitution already requires Groups to establish their own requirements. The OGB doesn't get to dictate what those requirements may or may not consist of, but someone who feels a Group is acting improperly is welcome to appeal. > Yeah, in reading the text of the constitution there is really nothing that > such a status would do, other than voting rights...whopee...Some > communities have more than a dozen contributers, like user groups for > instance. Again, I think Roy explained this well. The User Groups Community did indeed make a lot of grants that we might not agree with, and it appears that many of them will be discontinued as part of its reorganisation and merger with the Marketing Group. I'd suggest a bit of patience here - if you've been following the conversation on this and other lists, you've seen that things are absolutely moving in the right direction. > On the website itself, what is called a leader is merely a person that can > edit the pages of the community. That should be changed, a leader implies > much more than being able to edit. Just because someone needs to edit > doesn't mean they need to be a leader. > > I would encourage the OGB to draft up some type of guidelines and/or > change the name of "leaders" to "editors" possibly, it's confusing. Agreed; it's important not to confuse infrastructure artifacts with organisational structure. And the ability to edit web site content needs to become altogether independent of contributorship grants anyway. > I would like to see a distinction between those types and the types that > are contributing to ON. These are very different types of what is being > called leaders, IMO. We simply don't have the Constitutional tools to enforce such a distinction, even if we believed it were necessary. If we were to decide that the best representation for a consolidation's organisation is a Community Group, then ON's sponsoring Group would have the same responsibilities, constraints, and privileges that other Groups have. We could at most encourage such Groups to adopt common policies and requirements, but cannot directly enforce that. The system we have is very flexible, but it offers us almost no help in representing existing proven structures and processes. > If we allow this to happen in this fashion, we will end up with partial > kaos. Not that it is bad, just that we will have so much different between > the communities that it will make it more difficult to deal with as a > whole. We can't force people to work together who don't want to. All we can do is give them tools to accomplish their goals and global frameworks for resolving their conflicts. I still believe that a more rational and consistent view of this community would consist of perhaps eight to ten Groups representing vertical segments of the software stack and another handful representing horizontal layers (corresponding roughly to consolidations and ARCs). But it's very obvious that most people don't want such a structure, and don't believe they could be productive within it. As for the flexibility to include Groups not sponsoring projects that expect to integrate code into a consolidation, I'm glad to have it - it allows us to represent types of activity that could not have been otherwise. > I would like to see some way of starting by cleaning up what needs > cleaning, and try to align some of the communities together (based on > consolidation is fine with me, but currently we really only have ON). As Alan pointed out, this is not really correct. But I'd like to follow your line of thinking to its logical conclusion - please compose a list of Groups and a mapping from each one to a consolidation. > I thought it would be possible for communities to have some control over > their specific pieces, before placing that on the OGB and/or ARCs when > they're formed. The OGB does not make technical decisions, except possibly in response to an appeal of last resort. Like the consolidations, it's unclear how the ARC is to be represented in the new model - it works poorly as a Community Group, but again we simply don't have many choices. > I spoke with AlanC today and got the impression that some of this might be > a little early and that we should wait for things to be put in place. Yes. We're still working on Group reform, and haven't yet tackled the more challenging problems of consolidations and the ARC, much less the really intractable ones like defect management. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
