Am 20.03.2011 17:37, schrieb Angela Byron:
Just to point out, we don't need "mini modules" to accomplish this.
Drupal.org <http://Drupal.org>, being a Drupal site, runs "real"
modules. And by virtue of being on this list, we all know how to code
them already. We also have a customizable dashboard in everyone's
profile that reads in Drupal blocks, which is just implementing a hook
in said modules.
So if you want to add functionality to Drupal.org <http://Drupal.org>'s
user profiles, submit patches against
http://drupal.org/project/drupalorg (most likely new modules under the
"blocks_and_nodes" sub-directory there as a place to start). There's an
installation profile at http://drupal.org/project/drupalorg_testing that
gets you up and running with the set of modules that drupal.org
<http://drupal.org> runs and some basic data.
I think the proposal rather targets an open application framework
approach (aka. "Apps") that is known in many different ways:
- Facebook Apps
- Google account services
- Mozilla Firefox/Thunderbird/etc Add-ons
- Browser user scripts/user styles
- ...
I.e., there's an unlimited amount of possible apps/plugins/modules,
literally everyone can create and release new ones to their liking, and
there are no changes required for the affected platform at all. Every
user in the community decides which one they want to install or apply on
their own. In the end, implementation functionality and maintenance
burden is moved away from the primary platform, and the quality as well
as usefulness of an app decides on its popularity, usage, and adoption.
To a very limited extent, that's more or less what Dreditor is targeting
- it tries to fulfill the needs of drupal.org "power users" without
requiring any server-side changes. However, it's currently limited to
pure UI tweaks that can be performed via JavaScript. Once Drupal
exposes more of its resources via web service APIs (REST/JSON), Dreditor
will be able to do much more - a lot more.
Now, except for HTML5 Local Storage, Dreditor does not have any other
means of handling user data and related information. If you'd consider
that Dreditor would be available in an d.o apps directory and would have
a dedicated storage space per user on drupal.org as soon as a d.o user
installs it, all of your wildest dreams would become reality (and I know
you have 'em too, as you already filed some crazy feature requests ;)...
But that's just one of many possible use-cases. Given a proper
framework and API, most of what has been mentioned and what is flowing
around in terms of ideas to improve the user/support/help experience
could be implemented in various ways. Why have all of those sheer
endless discussions about how to do right to please everyone? Of which
most still have no result after years of discussion? Just let there be
1-10 experimental apps per problem space that attempt to solve it, and
while doing so, directly solve the problem for the time being. The best
approach wins in the end.
Bottom line: The apps approach provides many benefits. Instead of
deciding top-down, the community freely decides bottom-up, without
requiring a top-level decision at all.
sun
