[development] #drupal and #drupal-contribute split (Was: Re: Proposal: Move all dev support off this list to new StackExchange site)

[Daniel F. Kudwien]

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