SoC 2009

Overview: Parsing node content and auto generate taxonomy (semantic cloud).

Description: To be done: First and most important step: Find words, wich are significant. The faster - the better.
Step 2: Build structures from these words.
Possible tasks, which can be solved by "Auto Semantic Taxonomy":

• Language detection
• RDF'ing
• Spam Detection
• Autotagging
• User Matching (through node_profile)
• Meta Generation

In fact it's very similar to

• http://drupal.org/project/autotag
• http://drupal.org/project/autocategorise
• http://drupal.org/project/opencalais

but does it all in Drupal.

Main excercice: Write somthing like "opencalais" within Drupal.

Update: Now known as Awesometray.

Planet-SoC will be aggregating content from SoC contributers all over the world in a centralized location. Screencast demonstrations, articles, commits, you name it!

Are you a Drupal designer interested in getting some exposure?

Planet-SoC is looking for a unique theme to make Drupal stand out!

If you think you can help us with a design, please leave a comment or contact me or Alex UA!

Overview: Let users to edit a node at the same time.

Description: I proposed that last GSoC(Refactor Collaborative Editor), using one of VCS, Comet or AJAX. But now, like chyatt comment, there is google-mobwrite. And now it seems really a better idea(awesome? :p).

Mentors:

• needed

Difficulty: Easy?

On the recommendation of Alex UA, I'm creating this post to generate a list of potential mentors for the 2009 GSoC. If you're interested in signing up, please post a comment in this discussion.

It's that time of year: we have to figure out which ideas that we want to see happen for the Google Summer of Code. In the past we've created a document on the gsoc section of Drupal.org ( http://drupal.org/google-summer-of-code/2009 ) that lists the official ideas, but I'd like to also use the group here a bit for this purpose.

Towards this end, I created a new term for "Official Ideas", and added a listing of those posts marked official as a tab on the group: http://groups.drupal.org/node/18103/official-ideas .

I'm not sure if anyone objects to me creating the list this way, but it seems a bit better to have it here rather than over on the documentation page. I'll move the ideas to the documentation page as we move forward, but my plan is to use groups.drupal.org for all planning (which I consider this to be).

Any objections?

Overview: The Recommender Bundle provides a set of modules that generate recommendations and personalized views in a wide range of areas. For example, "Customers who bought this also bought" for Ubercart, Facebook-like new friends suggestions for social network sites, Youtube-like related videos for media sites, or the classical example of generating personalized node recommendations based on users access history, and much more.

(Side node: does my "include the word awesome" quota include the subject? ;-) )

Overview of awesome: Building installation profiles is currently difficult. Inconsistencies, a lack of documentation, and cumbersome iterative testing results in frustration and overconsumption of caffeinated beverages. This must be awesomed.

Description of awesome:

I recently started using Drupal extensively over the last six months or so. It's awesome and I love working with it. A couple of weeks ago, much to the annoyance of the denizens of #drupal, I started looking into building an installation profile with a bunch of my usual customizations and presets for the various modules I use on more or less every site, be it my own or someone else's. The aforementioned IRC-dweller-annoyance comes from the fact that there's precious little documentation for this fun little jaunt, so I've had to bug 'em with a lot of questions.

The installation profile system is flexible, but that flexibility seems to come at a serious loss of ease-of-use. Does this module want its settings as entries in the {variable} table? Or does it want its configuration data stored as an array? If it's an array, what keys are used? And how are they used? How about adding a view to the system (not hard, but potentially tricky - are there dependency issues? what about potential configuration problems?)?

My idea for GSoC 2009 is to build an application, either online or offline (each has its advantages), to generate this installation profile. I'd envision the workflow to look a little like this:

• Present a list of modules to the user (everything with a supported build for 6.x, say). The user picks what they want enabled. Do dependency checking so required modules are also included. Order modules to satisfy dependencies (or just make the user do it).
• Present the configuration options for core, as well as for all selected modules. The user preconfigures all modules all nice-like, or clicks "use defaults" when they don't want to fiddle with it.
• For modules where you have to create items (ImageCache presets, Views, Panels, etc.), the user specifies the stuff to be loaded in at the start. (Now that I think about it, doing anything significant with Views or Panels might be difficult, aside from "copy and paste an exported spec".)
• The user can load in nodes (pages, etc.), generate URL aliases if Pathauto is included, and build menus to link it all together. (This step and the last might need to be merged--it's awfully hard to build a Panel that slurps in a node if that node hasn't been added yet, for example.)

This isn't a complete list and I'm sure I'm forgetting some stuff, but it's a start--I think the general idea is pretty clear. Obviously some of this would require participation from module developers (maybe a better import API for Views, cough cough); the above is playing pie-in-the-sky a little on that front.

There's some other fun stuff that could be done, too, and streamline a lot of the maintenance of installation profiles. The automated profile builder could, for example, build an "independent profile", which doesn't need to be packaged with a complete installation like Prosepoint or whatever. Instead, it includes the code necessary to bootstrap the profile from a base Drupal build. An independent profile could, during the installation process, get the latest supported versions of any specified module or theme if one doesn't currently exist (I don't know if functionality for this exists on drupal.org at present, but if it does it could be leveraged) and unpack them into the correct places. Instead of tossing around full-size Drupal builds for a given installation profile, now you're downloading a single text file and letting the system handle the rest.

Why is this awesome:

First, a little bit about me: I participated in GSoC in 2007 and 2008. Both years my project focused on usability, on lowering the barriers to entry to hit the ground running with open source software. In 2007, I was tasked with writing the framework for a package manager for Windows, to allow for easier deployment of open source software (just get people to download the conduit, the reasoning went, and they can grab whatever open-source software they like). In 2008, I wrote a set of tools that integrated with Visual Studio to ease use of the Mono Framework and testing on Linux.

This idea's similar in principle: lower the barrier of entry so people get interested and get hooked on Drupal. With a system like this (especially if it included that independent profile bit mentioned above), it would be relatively easy to quickly create quality profiles. And, perhaps more importantly, it'd be easier to get new people into Drupal because the preset profiles just work. You want a quick blog? Download simpleblog.profile, which sets it up as a single-user blog. You want a brochureware site? Download brochureware.profile, which uses panels for a cool-looking layout and drops in a low-key theme. Right now, Drupal has a reputation for being crazy-powerful and also being mean and a huge pain to learn at first. I know that when I first started with Drupal, I went to look at the preconfigured installation profiles, and was disappointed--instead of being able to see a quality working site right off the bat or being able to hit the ground running with a site that was mostly configured the way I liked it, I found out I'd have to start completely from scratch. I got over that hump--the second time I tried to learn Drupal, the first I got confused and quit--and absolutely love Drupal now, but that's not the case for everyone who encounters it. It's easier to just say screw-it and go find something a little easier to start with, y'know?

All in all, I think it's a tool that would provide some pretty considerable benefits in the adoption and ease-of-use areas. One might even call it awesome. ;-)

Mentors:

• ?

Difficulty: Medium when it comes to writing the code, but Hard in terms of length/duration. It may be more than can be done during GSoC. (If I was chosen, I might try to make it my Senior Capstone project for my degree program, which would keep me on the project through May of 2010, at the least.)