my.drupal.org

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
catch's picture

Thought it'd be a good idea to start a discussion specificially on how this might work.

This is a very rough outline from my first post on this subject Drupal.org the redesign - high level.

If you haven't read that thread, this one will make much more sense (and hopefully be more focused, if you do that first. You should also look at these two related discussions where ideas are being thrashed out: Drupal knowledge base and video.drupal.org

Here's a slightly edited copy paste from that first post:

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.

edit: Moshe also mentioned trying to make an entirely 'push' system where *.d.o sites create nodes with metadata (but no body) on my.drupal.org. I think we'd need title, taxonomy terms, groups, project, author, comment authors, hopefully subscriptions information, last updated/commented time to do this. And also it'll have to be insert or update to keep track of updates to nodes.

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/mysite as well)

Cross posted this to semantic web and Views developers group since I imagine we'll be making use of both in one way or another.

Comments

Re: Collections

sdboyer's picture

Given the relevance of the general og_panels model to the my.d.o discussion, I figured I'd chime in here with some encouraging thoughts/ideas for subsequent posts:

Although I'm completely swamped at the moment, when I get a free minute, I am going to be generalizing the basic og_panels & og_collections model to extend to users, and possibly also to nodes (so we'll have user_panels/collections & node_panels/collections, or something like it that doesn't duplicate existing panels functionality). It's the user stuff that's relevant to my.d.o, but I'd like to sketch the basic functionality so that folks have a sense of what's going to easily be possible. Please note that I've written this with the (presumptuous) assumption that user_panels/user_collections is the direction my.d.o will go :)

  • As with og_panels, each user will be able to attach as many user_panels to their...profile page? profile node? Doesn't matter how we do it, whatever we're using as the main 'view user info' functionality, you'll be able to attach panels to it.
  • Each of these panels will automatically have a panels context defined with the user's UID, so any content that's put into those panels will automatically inherit that context - i.e., if you stick in a buddylist, it knows to use the buddies for that uid.
  • Even if they don't make it into panels core, or even into user_panels, I'd encourage folks to think about creating panels content items to fill out these user profiles in ways that are interesting & relevant to the my.d.o mission.

Where there's likely to be a lot more debate here is with user_collections. Whereas the user_panels will allow individual users to define the appearance of their own profile, user_collections can be the tool that allows my.d.o admins to define the set of user_panels that each profile will be automatically built with. In other words, the user_collections configuration would be what 95% of the my.d.o profiles look like, given that most people are unlikely to change their profiles too much :)

User_collections will do two other important things:

  1. Site admins will be able to 'push' updates into existing profiles (or at least make that content available to existing profiles & notify users of its presence) when new content types are added to the user_collection(s). In other words, if someone comes up with a killer new content type for user_panels but there are already 50,000 my.d.o profiles, site admins will be able to automatically and easily inject that new content type into each of those existing users' user_panels.
  2. Users will also be able to 'revert' changes they make to a user_panel which has a corresponding panel in the user_collection using a simple and easy interface. This should make my.d.o a LOT friendlier, as it means folks will be able to experiment without fear that they might irreparably junk their profile.

One other thought to chew on - if we go this route, it's quite possible to use a user 'typing' system (say, like http://drupal.org/project/nf_registration_mod, although that's just one method) to enable different user_collections for different user types. In this vein, we can also change the set of panels content types that are available to be added to user_panels based on those user types. Is this something we might want to explore?

Coordination and collaboration

agentrickard's picture

@sdboyer

Much of the functionality you are talking about exists in MySite today -- but in D6, we want to use the Panels API instead of going it alone.

Before you get too far in planning new code, please take a look at http://groups.drupal.org/node/8780

Sam Tressler, merlinofchaos and I met at DrupalCON to discuss this merger.

Personally, I'd like to see a Panels Collections module that replaces both MySite and OG Panels. Panels Collections would let page collections be defined per user, per role, per group -- and really, per any other organizing principle.

A Panels Collection would consist of definitions for:

  • How much content can be in the collection
  • Who can view the collection
  • Who can edit the collection
  • Who can create new pages for the collection

And so forth.

MySite's concept of "default pages" for users would be upgraded to a Collection Template concept, similar to how My Yahoo now provides pre-defined pages.

The critical first-step in all this is http://drupal.org/node/223994

--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3

default pages and panels collections

catch's picture

Sounds amazing. I'd been thinking about stuff like my.drupal.org/developer (see webchick's mockups for developer.drupal.org for how that might look) - being able to take stuff like that, drop it into your homepage, then modify it would be very, very cool. Then we also get a situation where my.drupal.org/developer could have x amount of admins able to add new content etc. Really, really nice.

Hi Ken - Yeah, I do need to

sdboyer's picture

Hi Ken - Yeah, I do need to poke around with MySite more and see how that integration will work, but it's rapidly becoming clear to me that this generalized 'Collections' approach is something that I'm going to go about carefully and deliberately, as it clearly sits at the crossroads of a lot of different existing projects. I think Earl put it pretty well in one of his comments at your first link: http://groups.drupal.org/node/8780#comment-27933. From what I can tell, it's at that point that you started to "Drink the panels kool-aid" :)

Earl also pointed out that the 'multi-page-collection' is something that the panels API could do, but at that time, there wasn't yet an implementation. Of course, now there's og_panels, and the superstructure of OG Collections that I'm working at building around it. If you haven't played around with it yet, I'd be very interested in what you think about the general approach I've taken with og_collections.

I'm heartened to see the outline of your response, though, because as far as I can tell, that's actually exactly what I'm aiming for in a generalized 'Collections' module - the ability to define page collections around a lot of organizing principles. I spent most of yesterday doing the initial round of changing og_collections over to an OOP approach, and simply doing that convinced me that such a generalized 'Collections' module is really not very far off, and can have a VERY pluggable API. The only thing I can't quite see my way through to from here is allowing Collections to be formed around arbitrary organizing principles - I suspect I'd have to write specific sub-modules for organizing around nodes, users, or whatever else (can you imagine panels_comments?)

Personally, my timeline has D6 ports a little bit further down - og_collections' infrastructure needs to get built and finished first, and Panels needs to get to rc status (there'll definitely be a beta4, but we may or may not need a beta5 before then) before I can think about the Panels port to 6. If nothing else, there are still some changes and kinks in the Panels API that need to be worked out before I shift mindsets into upgrading.

Cool

agentrickard's picture

I finally drank the kool-aid when Moshe wrote OG Panels instead of OG MySite -- both APIs support what he's doing.

OG_Collections is very much in line with a MySite Templates feature request I have been thinking about for a while now.

I want to focus on porting Panels 2 to Drupal 6 -- especially the API parts, so that I can provide a migration path for MySite users.

I think the OG_Collections concept can be abstracted to a Panels Collections idea -- or similar.

The only thing I can't quite see my way through to from here is allowing Collections to be formed around arbitrary organizing principles - I suspect I'd have to write specific sub-modules for organizing around nodes, users, or whatever else (can you imagine panels_comments?)

If you abstract out the owner/viewer/editor rules, then I think this becomes possible. Look at MySite, for instance. Right now, control over a MySite page is entirely controlled by UID -- the owner's user id. But if we abstract that a layer and call it owner id -- OID -- and have an OID lookup table that provides extensible rulesets, then I think it will work.

For instance:

OID    REALM   REALM_ID
----- --------  ------------
1      user       1
2      user       4
3      og         11
4      og         12
5      role        3

Then all your access lookups get done against OID, with an API for defining CRUD rules and so forth. Defaults could be written for users, groups, and roles. Let plugins handle other realms.

Personally, OOP would take the project beyond me; I'm not an OO programmer.

Sam Tressler and I had a similar conversation, so I think teaming up will be to everyone's benefit.

--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3

wireframes

catch's picture

Here's some wireframes - just posted to the flickr group. Pretty much ripped off from the netvibes UI, except we'd have much more semantic stuff going on under the hood I'd hope as opposed to just RSS feeds. Three types of page here: individual home page (which would be the logged in index), individual profile page, and pages for particular interests/groups (equivalent to netvibes universes).

Only local images are allowed.
Only local images are allowed.
Only local images are allowed.
Only local images are allowed.

Views Developers

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: