The thing I commonly find with forum/committee based systems is that they become very set in their ways. The systems become very difficult to change, and the hostility within these systems are most often sharp as a knife. Contrasty, open community based systems (like those found in "social networks"), are naturally less hostile, more flexible, faster to change with the tide, and able to meet a the needs of a much larger target audience.
This document is an attempt to reduce duplication, increase information accessibility and provide additional flexibility. In addition it will attempt to explain a system which will increase collaboration and decrease hostilities towards change. Thus promoting a healthier environment that accepts rapid change and reduces
I have seen, and even proven that the way in which a system is built directly effects the culture that is within that system. Thus carefully made systems tailored to their audience actually promote growth, improve communication, promote change, reduce hostility and reduce information duplication.
Time after time Drupalers (is that a word?) find the most brilliant ideas in the eyes of the new comer. Their fresh perspective is amazing, and sometimes brilliant, yet time and time again we crush these individuals hopes through miles of red tape and political mess. Often times this is a issue of conflicting ego's, other times its a resistance to change, while many times its simple pride. None of these reasons create a healthy social environment that benefits the community. I think the current Drupal system regarding changes to documentation and core unintentionally puts up these barriers. Its time to tear these barriers down.
Example of the problem with the current system is found in the way in which we manage documents. Currently if I disagree with the current document model I have about 2 years of work ahead of me to change it. That is IF I can get all the interested parties involved to agree to the new model. But as we have seen in the redesign of this site, and the many attempts to improve documentation, this process is extremely hard, if not impossible until the issue becomes critical and only then is it possible to change if the major players get involved and really start compromising.
The example provided in http://www.archive.org/details/GrouptheNewOrganicGroups-BuildingSocialNe... is amazingly accurate. OG has progressed to such a wonderfully powerful and flexible tool for so many applications that we should seriously consider it and its impacts on Drupal.org! Thus when I talk about groups I talk about them in the extremely flexible OG 3.x model seance. In essence, Groups are one way in which content is distributed and consumed. Which means that Documents, and Discussions could all belong to one or more groups.
If I create a group I should be able to add content to that group regardless of its type. Thus I can include a "fixed" ticket in My Group along with a Document someone wrote. As the maintainer of the group I can thus create unique relationships, formulas and recipes between content without adding duplication. If I create a group, I should be able to add content to that group regardless of its type. Thus I can include a "fixed" ticket in My Group along with a Document someone wrote. As the maintainer of the group I can thus create relationships between content without adding duplication.
If I disagree with how THIS group is run (for example), and can not get it to change, currently I can not "Fork" it by creating a new group. The "Forking" idea is not a favorable outcome but sometimes their are more then one valid approaches. If I decided to "Fork" this group, its not that I do not see this group as invalid, its that I see a different approach to be more valid to Me and/or My target audience. Its not a black or white world, its grey. I am not a threat to this group, I am simply offering an alternative for a different audience. The Drupal community does a great job at dealing with Forks of modules. We discourage it but do not prevent it. I purpose this same attitude towards groups. Also if someone abandons an active group, the same process of obtaining control that we use for modules would work in an open system of groups.
However I don't see "forking" in a group occurring any more then forking in modules occur. In my years in Drupal, I have seen things fork, only to later come back together a year or two later (Example, nodeprofile, bionode, etc) or stay separate and provide two distinct yet equally valid options (the commerce system, Notifications/Subscriptions, etc).