Making Drupal easier to find, assess and use seem like good fits for the Knight Drupal Initiative.
We all know that there will be a lot of work to do in the redesign, both for theming as well as module development. How about lining up funding for sustained development time and perhaps things like hosted d.o. redesign sprints?
That makes sense to me, but it also seems presumptuous to author a KDI proposal without discussing it first. So - how about proposals to set aside blocks of time (500 - 1000 hours?) to be used as directed by the Association in support of the d.o. redesign project?
Several such proposals might be made by different organizations / individuals, and/or there might be a unifying proposal that also includes allotments for hosting sprints.
Likewise, that basic principle might also be used to work on further Drupal usability assessments, structured assessments and then time for the right people to work on those problems.
Does anyone else have thoughts / reactions as to the appropriateness of authoring KDI proposals for either of those goals?
Comments
Packaging install profiles
I think a very specific area where the KDI might make a lot of sense for d.o. is in funding the packaging of install profiles directly on Drupal.org.
I would propose that this first get applied to the bundling of language-specific downloads of core Drupal -- i.e. click here to download Drupal in German, Japanese, etc. etc. This should provide the core functionality that is needed for application specific install profiles.
Generic work on d.o. is probably not as good a candidate.
Agreed, language-specific
Agreed, language-specific install profiles do make a lot of sense. And, likewise, 'generic' d.o. work is also not a good candidate.
In the case of the redesign, however, turning the Mark Boulton PSDs and recommendations into reality is probably going to be a massive project and would benefit from well-coordinated teams and sustained organizational focus.
There exist organizations in the community (and I'm not referring to ourselves) that would be well-suited to organize that work. If they had the ability to fly people in for d.o. coding / theming sprints or such, that would probably make it all happen a lot faster/better. Or, if they had the ability to bring their entire team to bear for a sustained period of time, supplemented by others as needed, that would also be good for Drupal.
Especially after all the discussions at the Szeged conference, I think this is a large enough priority for the Drupal community as it is fundamentally about making Drupal itself more accessible and easily understood.
So, anyways, it still makes sense to me as I think it helps Drupal move forward. But, that's just my $.02.
Drew Gorton
Gorton Studios
multi lingual by default? why a profile?
shouldn't drupal, by default, come with a lot (if not all) of languages in the core download? or to keep file size down, have some easy way of getting the languages you need as part of the install process (i.e. the install process should just ask what languages you want, you select the ones you want, and the installer get those for you). and yeah, you should be able to add them later via admin interface...
why would you have profiles just for languages?
Not just for languages
Various languages (e.g. Hebrew) need some extended modules / themes. Install profiles are a mechanism for doing out of the box configuration, setup, and customization. Rather than re-inventing the wheel, I think install profiles are a great fit for language specific downloads. The bundling / packaging scripts we have to build will also work with install profiles, so we get two features for the price of one. That is, this is NOT just for languages, just that support for just languages is an easy way to get going, with high amounts of motivation (there are lots of well supported languages). This gets us out of chicken-and-egg mode with install profiles in general.
So, we would have one download for each "supported" language. This gets us out of the hot seat of trying to decide which languages to include out of the box.
I, personally, have a really hard time figuring out how to support auto download securely, but that's obviously a second implementation that could work very well for both languages and profiles.
Usability
My read of conversations with Knight is that usability issues around initial installation and configuration could be a huge win for Drupal. This might inclue packaging scripts for install profiles (so that you get Views in your tarball, for instance).
While I do think there is room for some other UI work, the obvious first win is in polishing the initial user experience. The install sequence, for instance, could be followed by an optional tutorial walk-through. Maybe we can leverage Advanced Help to make a system that lets us provide that level of initial support.
--
http://ken.therickards.com/
--
http://ken.therickards.com/
thumbs up for packaging
Absulute +1. Just today I thought installation profiles hardly make sense without automated packaging. And as the project grows and grows, profiles appear the only way to cut through the Jungle.
Also thought: What Drupal-Specific service might I want to offer? Ah, Install profile would be nice. But in same instant thought: nah, what's it worth without packaging...
Life is a process
Life is a journey, not a destination