Groups.drupal.org are just as much an integral part of the Drupal experience as is the api or Association site. Drupal provides enough tools for different groups of people to manage the content of different areas of the site independently. This should provide enough independence to different groups to run an area to best serve its visitors.

At the moment you cannot get to groups directly in the primary Links main menu. If we have subsites, it definitely needs a clear Navigation to link them all.

Type your comment here.

I understand he will be creating the graphical widgets so it can be reused while still maintaining consistency. I think this is a great approach. As long as each element doesn’t come off as too generic, I think that’ll be enough to tie each site together while giving some flexibility and variation between sites.

There should still be limits and guidelines so each site doesn’t have to be relearned. Some of the ideas mentioned above on services to further connect each site is also great.

Another idea is to work out parallels where possible between different installs to allow linking back and forth. For example, the handbook pages can become a jumbled mess with comments.

If each page in the handbook can link to creating an issue queue or a forum post, it would be a lot cleaner. If there’s a mistake on the page, one click can create the issue and alert doc contributors. If an issue is already created, it will link to it. When the issue is finally closed, it will automatically place a log in the history and revert to a link to create a new issue. Forum posts can just link across the installs.

If there are other areas where connections can be made, it would really help in making everything feel seamless. I’m sure this won’t be easy but we can try.

i should say, until i read this thread of comments i was resistant to ‘diluting’ the drupal site, and dispersing the community, segregating developers from end users, making it hard to find content in hidden sections. those were my main concerns (as an end user). i had seen the drawings by catch about my.drupal.org but i wasn’t convinced.

comment 18 by eric atkins sounds like the kind of dispersal i was worried about.

now i see that instead of the forums (talking to an empty room) users will be encouraged to connect locally (local groups, like DrupalUK) and find like minds with similar needs tasks (Drupal in Education, Profiles as nodes, Zen theme users, etc). then they are finding solutions.

the docs would be managed in their own tidy area (i love the friendly ‘edit’ links of jquery’s wiki). that sounds like a huge improvement!

if moshe can solve the unified login and unified search- then we’re golden.

i get it now!

“doing that requires having a unified nid keyspace across an arbitrary number of sites that do NOT share a database.”

What says they can’t share a DB? They’re all going to be talking to the same DB server at OSUOSL. Why can’t they share some tables if necessary? If it was all D5 and we still had the nice {sequences} table, that’s the only one we’d have to share. D6 does indeed make this problem much more difficult to solve.

I guess a big problem with sharing any tables at all is that you have schema skew across version skew and you can’t have both D6 and D7 using the same table (at least not core tables). However, we certainly *could* have a shared custom table that wasn’t part of the core schema if that somehow helped us solve this problem. I’m not intimately familiar enough with the D6 autoincrement changes to know if it’d even be possible to solve this without patching core. Maybe it’s a lost cause. But, I really think it’d be so much nicer for usability if we could maintain a unique key space.

The Drupal.org group of sites could appear to be different sites visually (and have different subdomains) while at the same time being one site installation and database.

On the other hand, the site could appear to be visually the same across the board so it appears as one site, but be served by multiple sites and databases.

From an information architecture perspective there should certainly be separate sections/sites and landing pages for the various audiences and uses. From a visual perspective they should be coherent and conistent across the board so that the user never feels they have left the Drupal site/community when moving between the different components.

From a systems architecture perspective the sites should (ideally) all be one install/database. Having the users, roles, permissions, blocks, content types and views all available to any of the different sections/sites would be invaluable, providing the capability for more advanced features and better user experience.

One critical example is having 1 user account across the board. Also, it would allow much closer integration between projects and groups. A project page could have a view block listing of posts in groups that relate to that project. A group page could have a list of related projects, issues, patches and other important information to help users keep updated and get involved.

The downside is that it becomes a much more complex site and more difficult to manage and update. Because of this it makes sense for the sites to live as separate installs that can grow and evolve more quickly.

If that is a necessity then it’s critical to have plans and a framework in place for APIs/Services between sites (Services module and XMLRPC?) so that the sites can have more control over sharing users, content, views, etc.

Michelle