Community Segmentation, Bad News?
What brings me to this topic is all the excited talk I've been hearing second hand about splitting groups.drupal.org and drupal.org into many separate chunks (documentation.drupal.org, news.drupal.org, groups.drupal.org, downloads.drupal.org, content.contributed.maintained.6.modules.downloads.drupal.org , you see where this is going). What worries me is that in such an implementation it may become too complex to get to key areas or discussions.
The way I see it, there are a couple major roadblocks for making such a system work (here comes the dreaded Robin-list, grab some coffee):
- Unified login (no, openid isn't the solution, we have existing accounts on the sites and all those need to be unified).
- Domain complexity, in my last example above, we can't expect people to remember that. We need to have only primary level subdomains. EG: news.drupal.org, but not, modules.downloads.drupal.org.
- Unified search (this is very important, we want people to be able to find the resources they are looking for). We also need to be able to isolate the searches per content types, per site. So you can search for polls on groups. directly from any other site.
- Unified look. I don't suspect this will be a problem, bluebeach will need to be modified just slightly to show you're at a different site)
- Unified input formats. Right now, you can use markdown on groups.drupal, but not at the drupal.org forums. We need to allow the same syntax to be used everywhere
- Unified front page options. For maximum usefulness, we'd need the moderation options for "Show on this site's frontpage" as well as "Show on drupal.org frontpage".
- No link left behind. We need to implement either redirects from old links we'll be moving, or have a system to search all the sites if a unavailable page is requested. We have a lot of sites that link to nodes on drupal.org, and if we loose those, we loose a lot of useful external documentation.
- Clear cut reason why this is needed. I personally don't think this level or decimation is necessary, or even useful.
14 comments:
"What worries me is that in such an implementation it may become too complex to get to key areas or discussions."
Which makes it rather strange that you choose to publish this comment on a blog, rather than in the appropriate issue queue or mail thread.
Or for that matter, here: http://groups.drupal.org/drupal-org-redesign-analysis
fwiw one of the proposed subdomains is my.drupal.org which if done right would make things much, much easier to keep track of than they currently are.
I was one of the early proponents for this kind of split, and I agree that it can be taken too far. No one's suggested the modules.downloads.6.drupal.org kind of silliness, though, so as long as we stay dedicated to smacking anyone with a newspaper who suggests it, we'll be good. ;-)
The real problem is that tailoring the drupal.org experience -- and making the tools efficient -- is tremendously difficult if we're trying to make one site and one organizational structure target many groups of people with wildly divergent needs.
The requirements of someone evaluating Drupal for their business are different than those of someone managing a set of modules, or those of someone trying to pull together a working group to iron out some major API changes. I think that some sensible splits could help make that problem a lot more bite sized: projects.drupal.org as the project management/issue tracking infrastructure, groups.drupal.org for local and topical group organization, www.drupal.org for the front-facing information for early visitors, etc. The account/login centralization issue is a moot point, I think -- existing accounts are a nontrivial migration hassle, but they're also a one-time magration rather than an ongoing problem.
anonymous/catch, it was my intention to cross-post it into groups, I needed a few people to proof it first. You'll see it there in a few minutes.
Eaton:
"The account/login centralization issue is a moot point, I think -- existing accounts are a nontrivial migration hassle, but they're also a one-time magration rather than an ongoing problem."
I'm not sure if you're saying the point is moot because they will be migrated, or moot because they won't be ported. My worst fear would be to have to have a different account to rate a module, to post at the groups, to post on the forums, to file an issue, to run a unit test, to subscribe to the newsletter, etc. If that's the route we're heading, we'll be driving away users in droves rather than making their experience more useful.
OpenID can solve the login issue. There will need be a migration and joining / connecting of accounts, but if you're familiar with the Basecamp OpenBar, we can potentially have a dashboard across the top of your browser that allows easy login and access across all *.drupal subdomains.
This is a good list of things to make sure get covered. I think some amount of differentiation is ok on the sites (e.g. markdown on g.d.o, but not in forums, etc) but some standardization of the User Experience is obviously going to be necessary.
Much of this is being strongly considered though. I would recommend watching the video from the conference session on this once its posted.
Lastly, in terms of why its needed, for us "old timers" it's not a big deal, but for the community to continue it's diversification and growth, and still be inviting to the millions of great people who haven't yet heard of Drupal, things need to get both more complex (more types of info, language, functionality) and more simple (less clutter, more straightfwd).
Breaking things up into various contexts is the only way to go forward. Insuring these aren't a series of confusing and walled-off silos is the challenge. I'm confident we'll get there, as there are already a lot of best practices (e.g. Boris' comment inre basecamp_ to follow.
I guess having a Drupal site is not a part of being on "Drupal Planet" anymore? What in the world...
caleb? Not sure what you're talking about.
Hi Robin,
I'm poking a little fun that this is actually a *blogger* blog rather than, you know a Drupal blog. ;-)
I was thinking the same thing as caleb. Every time I'm forced to read a blogger.com blog it makes my eyes bleed.
Other than that I think that Josh and Eaton's comments are right on.
One big reason I would add for why this is necessary is that different parts of the D.O. world have different requirements, that require different modules, different content types, etc. For example, the reason why we are going to news.drupal.org is that we need to install (or create and then install) modules that are very specific to what we need to do, and we need content types that other groups don't need. Most of all, we want the ability to experiment with new ideas and implement new capabilities without the need to continually ask the already overworked volunteers who administer d.o. and g.d.o. for help.
Robin-
Did you get a chance to attend the drupal.org redesign session? There was some great discussion about these exact issues, why potential segmentation is necessary, etc.
While I think you bring up some good points that need to be addressed, check out the session for more information. I think there should be a video of it posted soon.
Mike, it's great this was discussed, but it would be much better in my opinion if there was a posted outline of the sessions results, so people like myself who were unable to attend don't have to watch the entire 45min+ presentation.
Robin
The writeup of the redesign session is here: http://www.lullabot.com/blog/drupalcon-drupalorg-redesign-panel-discussion
Post a Comment