Providing better content to its audience.

MGParisi's picture

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.

Content
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).

Comments

I hope you don't mind me

yoroy's picture

I hope you don't mind me crossposting to the Prairie initiative group, which is all about this problem… Thanks for writing that up.

Not at all.

MGParisi's picture

I have talked to some of the Dev community and I guess we can expect some resistance from people who believes that OG is too much of a strain on the systems and takes too much processing power. I can understand their concerns, but I don't know if they realize that the ability to find data, and the ability to put data in multiple places will reduce the duplication, issue queries, forum support requests, node count and thus could actually improve performance.

OG may not be the right solution. A custom solution that provides the features we need and the tuned performance required will probably be our best and only option. I do fail to recognize performance as a limiting factor. The performance issues can be dealt with, what we need is a green light, and then we can meet the performance requirements.

The truth is that from my experience we can expect a 2+ year lobby for this to actually get put in place. We will have hundreds of opinions and just a few people who disagree with it can hold up the process indefinitely. Most major paradigm shifts tend to only occur after it is too late, or when the need becomes so large and pain so big that everyone is faced with the nuclear option of "Just Get it Done".

I have been stuck in this situation before. I don't have the political power to push this idea forword. In fact I would actually welcome someone else taking this idea and the credit just so that it would get the attention it needed.


--Sig--
Owner of Toastyart a Drupal based High Quality Art Gallery.

Another concern

MGParisi's picture

Groups that are poorly maintained can quickly become spamming grounds. Captcha helps but many companies will hire low cost labor to get past this. Anti-spam fails and they find ways around it.

I do think the issue of abuse is important and should be addressed, but it should be a separate topic and is a separate issue. But it can be solved... for instance...

One quick solution that would need tweaking could be done through automation.
Sitewide moderation via the Web Admins issue Querry bogs down active members who have better things to do then to fight spam. Therefor a group maintainer that does not visit a group for a period of time will have his group automatically marked as "Needs Group Moderation" with a link to the process of taking over a group (just as modules are). After a period of time in the "Needs Group Moderation" state it becomes "inactive" and automatically locks, allowing people to view the group but locks the group from accepting posts. At this point only the moderator can unlock the group. A new user can request moderation, and thus take over the group and the moderating responsibilities.

Spam may also be handled via a flag or SPAM link. If content receives enough votes, it is removed from view by all but the group moderator, who can then over-ride it and allow the spam. In addition groups may also be marked as SPAM, and when these groups reach a critical number of votes, they too are locked. The voting system should take into account time and views.

Sorting groups by activity (or participation), amount of content, etc puts the job of getting noticed into the moderators hands. Sorting by amount of content is important to prevent older groups from receiving the most attention, thus receiving the most members and the most activity. Google has this same problem. The higher a page rank, the more prominent the content will return as a search result. Thus higher page ranked sites continue to get more traffic and more links!

If we use one table to account for all of this then the database will bog down. A system of multiple tables based on content type (groups, wiki, polls, events) or other criteria will alleviate this issue.

I present this issue not to be further addressed within this post, but to acknowledge the issue and to ensure that there are solutions. I have not given this solution enough time to fully develop, but WE can (over time or with experience) come up with a solution that works.


--Sig--
Owner of Toastyart a Drupal based High Quality Art Gallery.

Drupal.org needs a content

lisarex's picture

Drupal.org needs a content strategy.

The first step will be to audit the content we have. I'll be posting some first steps in the Prairie project.

==================================
http://about.me/lisarex

I think it's important not to

arianek's picture

I think it's important not to confuse groups with projects here. They were two different purposes. And there is an issue in the Docs queue for infrastructure improvements that will enable a lot of cross-linking between different content types on d.o - so if that fits in with these ideas, feel free to follow up. http://drupal.org/node/733908

Multiple ways to organize content++

mlncn's picture

Definitely approve the idea of multiple ways to organize the same content (and substitute content in different contexts). E.g., the Drupal 6 and Drupal 7 versions of documentation should be separate trees, but share nodes (but not necessarily all nodes).

benjamin, agaric