OK, this is a proposal for drupal.org's overall structure, drafted out of an irc discussion which lasted at least 2-3 hours.
In total, drupal.org + 4, 5, 6, 7, 8 subdomains
drupal.org
- Primarily for people visiting the site for the first time, or for the first time in a month or more. Big download link, not a lot else. this has to be ultra-fast, major news posted to it, site showcase content type, block aggregating front page news from subdomains, it has download links for core, it takes people off to where they need to go. Not much else. This could be built from scratch almost.
news.drupal.org new
- Similar to the front page of drupal.org, this would consist of Drupal-related articles, announcements, events, and show-case pieces that people would post. Then folks could rate them, and editors could "promote" them (or rate them with higher weights), and each month the top X teasers from each section would be consolidated into a newsletter to be automatically generated and e-mailed to subscribers (after a chance for last minute editing). (Optionally as a PDF? That would be great for promotional materials.)
- Using panels, the sub-site would stand as a showcase for news-oriented sites. Featured articles, listings of articles in various sub-categories.
- Alternatively, or additionally, it could be an aggregator from the other sub-sites, and even Planet Drupal. Having content aggregation be automatic, so it grabs promoted and highly user-rated pieces from the other relevant sections, would help to solve the issue of editor burn-out.
- This could be the front page of drupal.org, but having it be a separate subdomain allows for user ratings to change the weights of featured articles, which helps for community-moderated content to be later e-mailed. Once e-mailed, the articles would be marked with the Flag module (or some other implementation) and archived for that month. Then the next batch has its turn to be featured on the n.d.o front page.
docs.drupal.org new
- The handbook, maybe api.drupal.org (docs.drupal.org/api?). Essentially we start with a dump of drupal.org and rip out everything that's not in the book hierarchy. Then we bolt api.drupal.org on somehow (even if it's a prominent link and unified search).
projects.drupal.org new
- Downloads + issue queues, including support. This includes module and themes. This starts as a database dump of drupal.org, with everything ripped out that's not a project or issue. I don't think there's a clean way to separate out releases from support from bugs from development between subdomains - and it's an unhealthy split anyway.
either way - projects.drupal.org/ - aggregates new and popular modules and themes and stuff
projects.drupal.org/modules - probably not the full list, that's a level down for performance
projects.drupal.org/themes
projects.drupal.org/core
projects.drupal.org/profiles (but ideally this is /distributions or something)
projects.drupal.org/translations
projects.drupal.org/issues - the issue queue.
projects.drupal.org/support - maybe goes to a support landing page, including support issue queue (cleverly disguised as a forum), links to docs etc.
groups.drupal.org
- Much the same as it is now, with some enhancements. At the moment the docs team is discussing removing large numbers of the forums. Possibly all forum type stuff should be in groups, except support (which is in project.g.o). For example paid services goes here and becomes more like a classifieds section.
g.d.o possibly takes on mailing list functionality as well.
drop.drupal.org
- Hosts the DROP site. Very much as it is being hosted externally.
association.drupal.org
- No change
my.drupal.org new
mitigates the subdomain split, and provides a way to avoid splitting into any more.
It runs panels 2, views 2, feedapi. rips off netvibes.
my.drupal.org/ - customisable personalised home page
my.drupal.org/planet - souped up planet + internal .d.o news aggregation
my.drupal.org/developer - cool developer stuff (see webchick's original mockup for developer.drupal.org)
my.drupal.org/designer - ditto for designers.
etc. etc.
my.drupal.org/video - aggregates video stuff
my.drupal.org/foo- if 4-5 people are willing to maintain one, they get something similar to og panels collections to work with.
essentially my.drupal.org
Phase 2 of my.drupal.org might do this:
By using feedapi and feed element mapper, we make sure we get the uid of every node and comment into my.drupal.org. That way, rather than parsing 200,000 x4 tracker rss feeds (+ my issues), it can take four and process those. Then my.drupal.org knows about my issues, my tracker etc. fairly intelligently.
Once it knows this, if we install user relationships, and I make friends with cwgordon07, webchick and chx, then it also knows what patches they've got that need reviewing, which modules they just released, which cvs commits they just made etc. etc. This is one possible way to deal with the potential of a million or more posts a year across *.d.o within the next year or so. It'll also allow my.drupal.org to pull that information in and spit it back out as feeds - so on projects.drupal.org it could show me a block with 'recently downloaded by your friends' or something. But my.drupal.org does the donkey work for users who are logged in a lot, so higher traffic hit and run sites like drupal.org docs.drupal.org and projects.drupal.org don't have to (as much, anyway). We'd have to make sure that my.drupal.org/[nid] is masked some to avoid link rot since there's no need for it to accumulate information for years - it'll need to periodically clean out. We also want all activity to happen on the primary subdomains, with this just for convenience.
Additionally - my.drupal.org could potentially host my.drupal.org/your-user-profile - a configurable public profile for all *.d.o users - so this is centralised in one place (and probably takes advantage of panels/advprofile as well)
What's missing?
There's no obvious place for the forums to live, unless they can be folded into groups and issue queues (which I'd +1)
Single sign-on - actually this doesn't add that much to the number of places to log into, but we'd need open id becuase some people will need to.
Unified search - something like solr
Unified tracker - I don't want one tracker, I want 3-4 which I can view on one page, my.drupal.org handles this.
No cross posts anywhere - instead anything posted to the front page of a subdomain appears in a block on all subdomains to avoid unnecessary duplication and "wtf I just read this" moments. - my.drupal.org can be used to aggregate content and spit it back out again between the different subdomains
Comments
catch and I talked at length this evening...
He's offering to help kick-start the "bottom-up" implementation of the d.o redesign. Hooray for catch!!
Step one was doing the initial analysis to figure out who are target audiences were, what all the "stuff" was on the site we need to worry about, etc. That's basically all summarized @ http://groups.drupal.org/node/9034.
Everyone's pretty universally agreed that the only way moving forward is to split Drupal.org into several sites, both so that various teams could operate with relative autonomy in terms of the modules they install (wiki filters on docs.drupal.org, nodereview on projects.drupal.org, etc.), and also so that one portion of the site is not held up by another in terms of version upgrades, etc.
Now step 2 (this thread) is reaching consensus on where those barriers between sites are and talking about how to tackle some of the implementation issues around splitting the site content across multiple subdomains.
Overall, I'm really excited about the my.drupal.org concept. You create your own custom "Drupal home page" which contains exactly the stuff you care about.
The only other challenge that we didn't hit on is that of "link rot".. which is a biggie. Basically ALL of our nodes' content are going to change addresses, which will probably immediately destroy our google ranking. :P I would love to hear thoughts on how to get around this.
Good work
Agreed on all counts, especially the feeling of general happiness and heaps of praise for good work.
On the link rot question - I feel like I've got to be missing something, because it doesn't seem so daunting (I MUST be missing something - so this is my plea to please point it out).
Likely Flawed Logic Ensues:
All content will move, right? If so, we'll know (or be able to calculate) the URLs for said content and include that datum in any export/transfer process. The corresponding import can take that bit of data and add 301 rules that point old URL to new URL.
In the case of a subdomain switch (e.g. drupal.org/PATH to docs.drupal.org/NEWPATH), the rules for deciding what content goes to what subdomain will be clear. So, that means a two-step redirect (ugly) is pretty easy (e.g. d.o/PATH forwards to docs.d.o/PATH forwards to docs.d.o/NEWPATH). Much better, and only a bit more work, is taking the output of that import (PATH goes to NEWPATH) and sending it back to drupal.org. Then d.o can 301 drupal.org/PATH to docs.drupal.org/NEWPATH in one step.
Now, coming up with the what-goes-where guidelines might be terrible-nasty, but once that's solved, the technical challenge seems not-so-horrible.
So - I've got to be missing something big and obvious... but am bold enough to ask...
Drew Gorton
Gorton Studios
If we actually end up
If we actually end up hacking all handbook and moving it to docs. and all project and moving it to project. - then we can easily find out what the nid (and alias) is for all those articles. That ought to be the vast majority of the link rot, so it doesn't seem to be flawed logic to me.
Link rot
I know Google is a huge organization and maybe there's only a small part of it dealing with SOC and GHOP but I can't help but wonder if there's any contact there that can help? Surely Google has some search engine experts that could help with planning the Great URL Migration in such a way that doesn't destroy our PR? :)
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
yes and no
If we use 301 redirects (not hard to do) then we won't have link rot problems and they should find the new pages in a matter of days. It will be seemless for users even before the indexes are updated since the users just get forwarded to the right place.
As far as I know, google's policy is not to manually alter their index to reflect new url structures but instead to advise people to use 301s. That's a good idea since if we only fix googles index then all the rest of them wouldn't get the benefit that is provided by 301 redirects.
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
Also, 301s tend to transfer
Also, 301s tend to transfer (at least some) pagerank and the rest to the new addresses. IMO this is likely to be the least of our problems.
Ok
I was just responding to webchick's concern. I assumed there was something that 301s can't solve, but maybe not, then.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
link rot not likely a problem
Looks like link rot is not likely a problem as subdomains are treated much more like subdirectories of a domain, in google anyways.... http://www.naturalsearchblog.com/tag/subdomain-seo/
Even if there was some kind of shift in page rank i feel like it would most likely correct itself quickly, as a TLD like drupal.org has a huge amount of weight/gravity. I mean you gotta break some eggs to make a...
Anyways love the my.drupal.org concept, thanks for laying some important ground work Catch...
TravisC
'drupal' in drupal.org is a
'drupal' in drupal.org is a subdomain, a TLD would be .org .com .net etc
just putting it out there :P
vision media
350designs
Print Huge Edmonton Printing Services
Design Inspiration Gallery
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Thoughts
There's an inconsistency in the sub domains, for example two are plurals and one is singular (project.drupal.org). I think all the sub domains can and should be plurals to be consistent and predictable: all projects, all groups, all docs.
Forums and mailing lists probably do fit best on groups.drupal.org, perhaps discuss.drupal.org would make a more appropriate name though.
hmm. You're right they
hmm. You're right they should be consistent. projects.drupal.org is probably fine - or maybe code.drupal.org?
groups currently handles events and jobs (and is likely to continue to do that), so I think discuss would be a bit too restrictive.
talk.drupal.org?
talk.drupal.org?
hmmm
That might even solve the homelessness of the forums.
forums.do clearer
forums.drupal.org would be much clearer for most people. "talk" is ambiguous.
Graphics?
Do we have an plans or mockups of actually graphical designs that have been worked on? personally I think my boss Yura would be the perfect man for this job, he creates absolutely amazing designs and I am sure he would do this one for free.
Some of his work:
http://derksformals.com/
http://stationerystyle.ca/
http://www.lightrein.com/
http://shoeguru.ca/
http://350designs.com/lighttools/
http://edulisimports.com/
etc
vision media
350designs
Print Huge Edmonton Printing Services
Design Inspiration Gallery
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Mmm, Catch, this is going to
Mmm, Catch, this is going to ROCK.
Consolidate existing resources.
There seems to be a lot of overlapping/conflicting goals with this plan. One of the main problems with Drupal.org is that many related things are scattered all over the place. There's a lot of duplicate effort between the handbooks, the docs, the api lists, the groups, the forums, the mailing lists, the issue queues... The aim of any redesign should be to consolidate these elements, in order to increase the ease of finding information, and decrease the cost of maintaining it.
These should all be one resource:
my.drupal.org/docs
docs.drupal.org
my.drupal.org/developer
api.drupal.org
These should also be consolidated:
project.drupal.org/issues
project.drupal.org/support
And these:
my.drupal.org/planet
my.drupal.org/marketing
drupal.org marketing efforts
Improving the forums should also be a top priority. I'd wager 75% of drupal.org activity is in the forums. When people talk about the great Drupal community, it's the forums they're usually referring to. With that in mind, these should also be consolidated:
forums
groups
mailing lists (at least the ones that are better served by forums, like the support, themes, and developer mailing lists)
Right now, there's almost no way to know where to look for an answer on Drupal. It could be in a handbook, it could be on the API site, it could be in a readme.txt in a module, it could be on the mailing lists, it could be in a forum post, in a reply in the issue queue... chances are, it's probably in more than one, and possibly with conflicting details. This plan really needs to address consolidating existing resources first, before any discussion of adding new venues can take place.
Well the handbook and the
Well the handbook and the docs are the same thing, so I'm not sure how they 'overlap'. For that matter, I very clearly argued for consolidating both the forums and the mailing lists into groups.drupal.org (and the issue queues for support requests). I'm also not sure where this idea that the community exists primarily on the forums comes from - several hundred people contributing patches to D6 didn't do so via the forums, although that's where many people begin getting involved (as I did), it's not usually a productive place to have discussion or get help.
As to api.drupal.org - I think this should be as incorporated into docs as possible, but it's a very different beast compared to when code freeze is going to be, or a CVS update from dww etc., or new module releases, which is what I see my.drupal.org/developer being - probably I need to expand on how these might actually be used. IMO ther'es no duplication here though, apart from my.d.o which exists only to duplicate and hence avoid the need for crossposting.
defining community
I guess it depends on how you define community. I'm going by numbers here.
Several hundred people contributing patches isn't a large percentage of the 260,000 users on Drupal.org. People who contribute patches are a very important part of the community, but normal users outnumber them by orders of magnitude. This doesn't take into account the number of people using Drupal.org who don't have accounts, either. I just did a quick count, and there's over 426,000 posts in the forums. That's a pretty huge chunk of community activity.
I agree with you on merging groups, lists, and forums. I just want to emphasize how important the forums are.
It might be too early to say what is a duplication/overlap, but my general point is, we should try to avoid it as much as possible. My.drupal.org is an interesting idea, but I'm not clear how it isn't just rehashing what the other sections should already be providing easy access to. Is this essentially designing two user interfaces for the same information? Could this job be done by an RSS reader?
There's 780,000 comments in
There's 780,000 comments in total (minus deletions), so although there's some in the handbook, I reckon the rest is primarily issue followups. :P I take the point though. Having said that, I'm still pretty sure there's a much higher number of people who've used drupal.org/project than drupal.org/forum - since that's how you get hold of drupal in the first place.
sepeck has just deprecated some forums and is going to rename others, and I'm hoping that reorganisation will make it clearer how to integrate them into an overall redesign.
I've updated the wiki with some more ideas about my.drupal.org - I think it's got the potential to be a lot more useful than a feed reader.
Good update
"Once it knows this, if we install user relationships, and I make friends with cwgordon07, webchick and chx, then it also knows what patches they've got that need reviewing, which modules they just released, which cvs commits they just made etc. etc."
I like this idea, anything that brings more attention to patches needing reviewing is a step in the right direction.
One of the challenges in creating something like my.drupal.org is keeping it in sync with the data sources. This is something I deal with a lot at DrupalModules.com. The data interface must be carefully designed so that changes in drupal.org features don't derail services on my.drupal.org. If they are too tightly integrated, it will hamper innovation on either end. If this is going to work, it's probably a good idea to start looking at how data will get into my.drupal.org very early in the process.
Suggestion on events
I didn't know about the chat, alas. Maybe next time someone can post an event node here? I'm adding the iCal feed to my calendar, just in case!
PINGV | Strategy • Design • Drupal Development
The chat wasn't scheduled at
The chat wasn't scheduled at all, and ended up continuing on and off for more than 4 hours, starting at 1.30am UTC. Having said that, it'd be worth trying to schedule some irc meetings later on so it's not dependent on people happening to talk about thing randomly on irc in the early hours of the morning.
Instant Syndicating Standards
Hi catch,
my.drupal.org knows about my issues, my tracker etc. fairly intelligently. Once it knows this, if we install user relationships, and I make friends with cwgordon07, webchick and chx, then it also knows what patches they've got that need reviewing, which modules they just released, which cvs commits they just made etc. etc.
Perhaps this might interest you:
http://iss.im
If there is anything I can do, let me know.
Best regards,
Nick Vidal
I agree that many of these
I agree that many of these docs resources can be consolidated. But the question is: how? What is a more a effective architecture?
Also, I wonder how folks feel about annotation on "handbook"/documentation? Also, how do folks feel about community rating or review (like node review) on those pages?
I talk about some InteractionDesignIdeas that generally apply to wiki patterns at http://www.communitywiki.org/en/LackOfReworking#LackOfReworkingInteracti... some of which are currently possible within Drupal (all except the "merging" of "branches" which in this case are annotations)
The idea is to improve the problem of "lack of reworking" that has plagued wikis for years, by making the "reworking" process more closely aligned with the way that people are usually reading and interacting with the text. Process patterns that make people more likely to post "microcontribution", and that will make microcontribution more useful. Let people make notes as they read, and make it easy to append content with notes when applicable, or merge notes into content. (useful) Rating making it easy for everyone to find what most in community determine what is currently high quality documentation, and what still needs work.
I'll not be hurt if above suggestions are disregarded in the context of what you all are talking about here, but thought I'd throw them out here.
Also, I may be naive, but I wonder if there is a way to capture and post the notes/documentation that is put into code, when applicable? I fantasize here that people might put detailed notes into the code comments (which sometimes is the case), and that these could be output at documentation pages, which could be further developed.
Also, people who apply might be given permission to send email straight to a "draft" area, that are copies of emails to lists.drupal.org, via Mailhandler perhaps.
For forums, it would be cool to be able to move, flag, tag, or otherwise quickly recombine forum posts and comments into documentation. This way mailing lists, forums, and documentation pages could all be transcluded then reworked. Even stuff on groups.drupal.org could be transcluded, or any *.drupal.org site could potentially have a way to transclude/move content to docs site.
Once content is in there, it could be added to outlines, and could begin it's life in a review process for quality, and have annotation ("inline comments") access available. It's also possible that after a certain amount of time, that pages could be graduated to a non-"draft" status, if it pages (or outlined collections of pages) meet a set of multi-faceted criteria.
For API, it would be interesting to be able to quickly use a "link language" like freelinking, or some other easy way to link to those pages while you are writing a document page (same with all other existing pages).
These ideas are adpated from what are (in my opinion) some of the most useful emergent features and functions of wiki engines. I have been experimenting with doing some of this in Drupal wikis (or wikitools with outliner/books module).
Just some ideas, anyway.
Sam Rose
Social Synergy
Open Source Ecology
P2P Foundation
Sam Rose
Hollymead Capital Partners
P2P Foundation
Social Media Classroom
Conversation Pivots
I just noticed this: http://drupal.org/node/231653
Great!
Drupal already has some potentially great building blocks that could enhance (docs.)drupal.org
Sam Rose
Social Synergy
Open Source Ecology
P2P Foundation
Sam Rose
Hollymead Capital Partners
P2P Foundation
Social Media Classroom
scratch.drupal.org
...Also noticed it implemented on scratch.drupal.org (http://scratch.drupal.org/project/project <- example)...
I have worked with conversation pivots previously, and that is really awesome.
Sam Rose
Social Synergy
Open Source Ecology
P2P Foundation
Sam Rose
Hollymead Capital Partners
P2P Foundation
Social Media Classroom
Link Rot Page rank and search
IMH Drupal should not host it's own search. If we were to switch to Google custom search
It would take a big load of the servers.
Viewers would get faster and better results, etc
I all ready use Google to find things on Drupal. They only time it fails is when idem I looking for is very new.
Regards
Ron
You fail to account for the
You fail to account for the improvements that are being made to core search. This argument comes back to the idea that if we don't use our own search, we will not continue to develop it. So, as a person who suggested that we use Google search quite a while ago, and have since changed my mind, I have to disagree.
Although, I was under the
Although, I was under the impression that someone resembling yourself was looking into Solr to handle Drupal.org search - especially across multiple subdomains etc. cross-subdomain search is one of the two main blockers to splitting subdomains at the moment - the other being logins. We'll also need to account for the possibility of different subdomains running different versions of Drupal for up to a few months at a time.
Whether I've got that right or not, any ideas on that front would be really handy here.
There is that, too :P But if
There is that, too :P
But if we have a core search that is suitable we might argue to stick with it. My enthusiasm for Solr hasn't waned, but with core search and Xapian search improvements of late, there are great options. We should definitely host our own search, core or otherwise.
core point
People who want to use google can. But there are times when the drupal.org search is the best. If you want to search module releases tagged with a taxonomy term for a certain word, there is no way that an external engine can work as well as the internal engines.
So, to this:
Absolutely.
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
oh yes
If I'm trying to find an issue via google for some reason, I often get the patch instead (and understand why some people add issue numbers to patch filenames, very clever). So of course we need to host our own search - and efforts to get core search pluggable with different indexing backends are likely to make that core search regardless of what happens in the short term.
my.drupal.org
This can be supported by the proposed MySite / Panels merger in D6, or by MySite in D5 right now.
I would start thinking about my.drupal.org based on the existing features of MySite -- since we're already planning the upgrade once Panels 2 is stable. Then we can layer in "nice to have" features later.
But then, I'm a little biased here.
http://therickards.com/mysite-default
--
http://ken.therickards.com/
--
http://ken.therickards.com/
my.drupal.org/ Must have
my.drupal.org/profile-name
Must have provision for us to add our Social identity -> A Track me socially block. I think this is a must today.
We must be able to categorize the content we submit across the drupal domain and have list of our most most recent content on the home page. List of my categories as a cloud!
List all the groups I am subscribed to.
My Contributions in Drupal.
My Drupal sites.
Custom Feeds - say from my blog!
Netlink Technologies Ltd
http://shyamala-drupal.blogspot.com/
Shyamala
Unimity Solutions
Should there be a sub-domain
Should there be a sub-domain training.drupal.org or dojo.drupal.org --> Training should be more than a group in Drupal?
Also a subdomain for support, say:
support.drupal.org/forums
support.drupal.org/mails
Netlink Technologies Ltd
http://shyamala-drupal.blogspot.com/
Shyamala
Unimity Solutions
news.drupal.org
Added some quick notes for the proposed news.drupal.org section, which I still believe is a strong offering that should be considered.
Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
I still reckon that could be
I still reckon that could be handled somwhere like my.drupal.org/news - could have tabbed panels on there pulling information in from a variety of places quite easily without the need for a whole site.