How drupal/drupal.org could benefit from incorporting concepts from apps

  • Improve the update handler to add an installer that can parse a feed (or however is best) of modules, search, organize in some way so users can install modules from a drupal.org install that it, and it's dependency will be downloaded fromAdd an icon for modules (non-required, but it looks snazzy, man).
  • Have a way to make suggestion feeds (which d.o profiles can come with one) that the installer can default to showing. There can be multiple blog modules that are great, but fit different use cases. Different people will want to suggest different things to people/clients, etc.. D.o standard profile could come with one that community has voted on is good
  • Incorporate the install new modules with site install workflow for standard profile
  • Improve workflow around finding modules (rating system?)in general

Apps idea doesn't deprecate distro -- a distro can become a base set of features the author thinks is vital for functionality and a suggestion feed for other functionality to expand on that. IMO, all parts of a distro *should* be separable from the distro itself and re-usable; the distro is a example/easy set up of that set of features (where the distro is a type that is featurable type functionality -- pressflow would not fall under this).

Most important: Get All the damn open sourced/public features/app/whatever off of github/feature servers/app servers/etc. and into drupal.org so people can find em/collaborate on them/etc.

Tags:

Comments

Grayside (not verified)

Thu, 01/26/2012 - 08:28

I believe I've seen core issues and discussions around all of those points. You should find the conversation, too many people focused on Distributions don't speak up.

Agreed with getting Features onto D.O. I used to love the idea of Feature Servers, and they still make sense if you don't want to release your code as GPL, but collaboration helps. It turns out that good features are not actually trivial. Collaboration can produce meaningful results.

The real problem though is meaningful namespacing. The more people that try to work and collaborate in this space, the more important it is that some of the seemingly trivial guidelines in Kit be applied. (And also the more important that something smarter happens with Features component conflicts.)

Add new comment

More information about text formats

Filtered HTML + code filter

  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.