By Bèr Kessels on
update:A final roadmap is now placed in the books
I compiled all battle plans into a single document that lists most mentioned battle plans. This way we can not only group our efforts better, but outsiders can see in genrel where drupal is heading and what needs still to be done.
This is only a proposal, I will not publish it in this form if anyone does not want his name released, or does not want to work in a "team". In both cases I will remove the names.
If you want to be added to a team, or want a new "project" with "projectgroup" added, please comment too. In a week from today (28 october) i ill publish this roadmap.
Note that it is nowhere near meant to be a contract. It is merely a tool to group and organise our efforts better.
| Task | Modules/Areas | Team of volunteers | status |
|---|---|---|---|
| Theme improvements |
theme system; block system |
Neil Drumm Chris Messina Halfelven |
WIP |
| Design themes | themes |
Mega Grunt Bèr Kessels |
TODO |
| End-user documentation | drupal.org; help hooks | Bert Boerland | WIP |
| Internationalisation i18n | i18n; locales |
Jose A Reyero Carl McDade Bèr Kessels Adrian Rossouw |
TODO |
| Translate interface | locale; po files |
Bèr Kessels Gerhard Killesreiter |
WIP |
| Meta-data approach introduction |
flexinode; node |
Jonathan Chaffer Bèr Kessels Neil Drumm |
WIP |
| Search improvements | search hooks; search module | Steven Wittens | WIP |
| Install system | core; modules | Adrian Rossouw | TODO |
| Move to business area | core; modules (drupalCOM) |
Jose A Reyero Bèr Kessels |
TODO |
| Move to project area |
project modules, groupware |
Uwe Hermann | TODO |
| Improve content organisation |
mindmap.module book.module |
Gerhard Killesreiter Magico |
TODO |
| Improve menu system | menu.inc; menu.module | Jonathan Chaffer | TODO |
| Improve and fine grain permission system | menu system; core; | Jonathan Chaffer | TODO |
| Improve block administration |
block.module theme system |
Neil Drumm sandip |
WIP |
| Fund-raising and marketing | drupal.org | Lapurd | WIP |
Comments
improve taxonomy system
modules/areas: taxonomy system; rss syndication
team of volunteers: jvandyk; mathias
Taxonomy: standardize vocabulary metadata; open/closed vocabularies; interface to vocabularies in ways other than simply a selectbox
Publish/Subscribe: share and aggregate vocabularies among Drupal sites
I think I am going to touch o
I think I am going to touch on RSS (and maybe even ATOM since ideally it will be trivial to do so) depending upon how well my API changes for node listings goes. I guess this fits under "Meta-data approach introduction"
RSS 2.0 with 'enclosures'
I am interested in getting Drupal working with PodCasts. This is just an audio file enclosed as a link in an RSS 2.0 file.
More info:
http://www.ipodder.org/whatIsPodcasting
http://ipodder.sourceforge.net/
http://www.podcaster.net/
Cool idea! Anyone else interested?
Enclosures
I have been following the podcast developements the past month, and enclosures would be nice to have (not just for podcasts). For this to work, you need to make the RSS feeds extensible so that modules -- the upload module in this case -- can extend the feed's items. Neil Drumm prototyped such changes a while ago. Maybe dig the patch queue and/or the mailing list.
how far to go?
I was thinking it would need to integrate with the upload module. Initially I will probably just do a hack to get it working for the basic needs of a podcast.
It will probably be a fair bit more work to integrate everything in an elegant way and make RSS feeds more generally extensible, but I agree that this should be a goal.
Good to hear that some thought has gone into some of the issues already! I'm not interested in re-inventing any wheels.
Right, that is at the end of
Right, that is at the end of my list for things to do about node listings. Mostly because I think everything else needs to be coded first before there is a nice home for this code.
If you need something now just make a whole module to do it and output some custom RSS feeds.
Cheers
No problem with that. A two stage approach suits me fine.
First a prototype module to help define the functionality and user interface, then a well thought out, and integrated implementation that is more extensible.
An initial module may also help gauge interest. No use doing a lot of work if it's not going to be using it!
Thanks for commenting
Replacement Modules / Include for 4.5.2
You can find a replacement node.module, upload.module, and includes for the 4.5.2 release to implement RSS 2.0 feeds with enclosures (the enclosure tag) at this location:
http://writtorrent.sourceforge.net/2005/02/rss-20-feeds-with-enclosures-...
Thomas Winningham
http://writtorrent.sourceforge.net/
Will these modules work with
Will these modules work with 4.6 as well? Or will they break something?
Some thoughts on enclosures for the RSS feeds:
1. I can imagine a number of situations where the enclosure might
not be hosted on the same site as the RSS feed is coming
from. I know that a number of folks are using archive.org
for data storage and then point the URIs there.
So, along with attaching "local" files there should also be a
mechanism for remote files as well.
2. Whether the data is local or remote to the machine providing the
RSS feed it should check the enclosure for both data type and
file size.
just my thoughts.
Design Themes
I'd like to be added to the design themes team, if the other team members don't object :)
adrinux
adrinux@ntlworld.com
Adrian Simmons
adrinux@anaath.at
Improve image module, etc.
We made some improvements to image.module in 4.5 timeframe, but a lot more needs to be done. I still have a need for some of the proposed improvements, so I'll sign myself up again and welcome participation from others (Bruno? Gordon? Scott C?).
Dries and Stefan join various teams
both Dries and Stefan emailed me that the plan to join and help in various parts,
Stefan Nagtegaal would like to join:
'Theme improvements',
'Design themes',
'Translate interface'.
I did not add Dries, since I sort of assumed him to be our big boss :) Or better, to help here and there, but most important to keep overview on what is happening. I dont think its a bad idea if more people would help with this, we can then add a row at the top called
"supervising" or so, containing the team that will act as the glue for all other initiatives.
[Ber]
Thanks. I do intend to help
Thanks. I do intend to help in nearly all areas, especially in the work-needing ones. That said, I plan to take on several (smaller) tasks myself. What these tasks will be, depends on what I enjoy working on most at that time (it's all about having fun), or what it is deemed important to work on. I can't tell you up front what these tasks will be, but chances are they are in my mindmaps. Right now, I'm working on improving Drupal.org, or features that help improve Drupal.org. Usability improvements are always high on my list too.
Fun!
working on Drupal should all be about fun!
By no means, the above-posted table should stand this in the way. OSS is all about fun and itches (and scratching those). Keep in mind that joining a group and getting listed is nothing close to any contract or such! Its about making visible who is doing what.
So, if you do not really enjoy working on a part, please tell me so too, then I can remove the names from the lists. Also, if tasks look like no-one is working on them, report that too. please, never feel obliged to code on something you don feel like, just because your name is on a list!
Ber
Needs more definition
I think this is a great tool, but each item needs more definition. There should be a paragraph about each one. I have NO idea what "move to project area" means. Also how does "improve block administration" and " Theme improvements" overlap as they both talk about block.module. With out that next level of detail I have no idea how changes I might want to make need to be communicated.
I'd also like to see some serious improvement on our file handling capability. There are some big holes still in that area in both the core system as well as the contributed modules (mine included). Unfortunatley I'm not sure how much time I can commit.
My plan for blocks is contain
My plan for blocks is contained in http://civicspacelabs.org/developers/proposals/theme/implementation. You should poke around that book page's siblings to get an idea of what the CivicSpace wants out of "themes" (really layouts, code standards, and themes). Pages like http://dev.bryght.com/t/wiki/BlockHacks are an excellent TODO list of things to make less hacky.
true
But I hope that the taskforces themselves will come up with some documentation.
Then my plan was to link to that from the description.
I do not have the time ,nor the knowledge to describe all the tasks in the table.
About the "move to ..": it means that those groups will look into it, that drupal can be implemented in that area. So "move to project" means that drupal can be used for projectmanagement,
[Ber]
Battle Plans for Bryght
We've got lots of battle plans. Here are some of the things we're going to work on:
* documentation: end user documentation, admin guide documentation
* fund-raising and marketing (yes, for Drupal as well as for us)
* theme improvements
There is lots more, but we're too busy coding to sit down and list a bunch of them...
There is lots more, but we're
It would be much better for the community if you took a little bit at this point and outlined what you want to do. Otherwise I may do exactly the same thing you are instead of working on another area.
Yes, I agree. A lot of the st
Yes, I agree. A lot of the stuff we're working on is for our hosting business, so isn't necessarily core Drupal stuff. We're absolutely not going to work on any specific components without gathering together anyone else interested in working on the same space.
In general, event needs some loving, so that's another area we'll be involved with. We're meeting with Dries and the CivicSpace guys next week, so we may have more to say then.
Event module
I belong to a group that is porting it's web site to Drupal and have been extending the event module. So far I have added
The ability for 'moderated' posts (the status is 0 unless approved by a moderator)
I have added a 'add event' link to the calendar and each event so it is more visible to users.
I have added an end date and time
I added a new page for only 'selected' upcoming events (we use this for our front page with a link to the complete list) Only the moderator can make the event 'selected'.
I added the ability to specify a taxonomy term as indicating an event is a meeting . Meetings by default show up on their own list but can be 'promoted' by the moderator to also show on the event list.
Meetings have their own class so a theme can make them different from other events.
A number of structural changes to the list of fields table
The ability to set help messages for the selected upcoming events, upcoming events, meetings and calendar.
I have probably forgot something.
On the to due list
Add the abitity to specify the event as 'site hosted' and on output if there is an image defined, place it before the event title
Add support for recurring events
Code?
It would be nice to see some of this code. Do you have a CVS account? You could upload your code to a sandbox, so that others can check it out.
moderated: how is this different from using the queue?
Make code available
Being new to Drupal I am unaware of the sandbox sand do not know how to get a CVS account. I am willing to make the code available,
With the current version of the event module a user can either make events or not. All events posted have a status of 1.
I added a second permisson (similiar to the comment module) so that some users can post directly and others go through the queue.
fund
I have been playing around with the idea of fund raising for some time. I would like to help out there, making some kind of spreaddrupal.org site or combining paypal/google adsense money as well as paying up my self
a drupal ad on the frontpage of NY times? ;-)
If you need help with fundraising, I am willing and able to help out.
--
groets
bertb
--
groets
bert boerland
>>bertb >>If you need help wi
>>bertb >>If you need help with fundraising, I am willing and able to help out.
In my oppinnion, it would be wise to agree to see things separated here, or recognize them as separated interests. We can all help each other by doing this. For example one task recognized for specific Drupal marketing/promoting/fundraising and another task for the actual handling of donations and all related to it.
You do not build a 'spreaddrupal.org' site and only for that very same site custom/dedicated donation code, because then you isolate the true potential effectiveness of Drupal donations. Handling of donations and actual fundraising should be seen as two separate things. If a donation solution (hint, hint) could much more effectively tackle the handling of donations by being dedicated to that interest, I suggest that approach. That way 'spreaddrupal.org' can specialize in marketing/promoting/fundraising AND benefit from a dedicated donation service on top of that. (I only took 'spreaddrupal.org' as an example as you indicated that as an example)
fundraising
First of all i suggest you open up a project called "fundrasing"or so, to vbundle code, ideas and discussions, for this is not the ideal place to discuss those.
However, I suggest you people take a peek at how mandrake shaped their funding: "if you pay, you are guaranteed help, support and attention". somthing like that. Drupaleers (developers and supporters) should then offer hours and some sort of coded "marketplace" could compare the available hours against funding. If one wants a solution (bug fix foir example) "right at this moment" he/she should donate, in order to get one/more of these available hours.
[Ber | Drupal Services webschuur.com]
Drupal fundraising or general fundraising
As I work for a non-profit organisation, for which fundraising is an important part, the topic of a 'fundraising project' caught my interest.
Actually, what most people seem to be talking about is a Drupal (specific) fundraising and marketing project. I think that is a very good project to follow up on, I just thought it might be worth distinguishing it from using Drupal as a platform for fundraising activity
Could this proect be called Drupal fundraising?
This would leave room for a possible future project to add features such as a fundraising.module to Drupal, and avoid confusing people interested in fundraising for their own organisation/charity.
I say all this because I'm implementing a fundraising software solution where I work (reluctantly), something more along the lines of CRM software for non-profits and charities. If there had been a compelling open-source alternative I would have recommended it instead of spending £10,000 on this: http://www.blackbaud.co.uk/solutions/fundraising.asp (windoze-only proprietary thing) I even have to use MSSQL Arrrgghhhh!
Donations != fundraising
My input is not about fundraising, I can be about donations and donation functionality itself. This is a fundamental point to make clear, what is talked about on this page is a funding mechanism or fundraising mechanism and marketing, but donations are donations and a funding mechanism is something else.
Drupal allowed not just to make a donation solution for itself as a module (which would only work in Drupal based solutions), but it allowed the creation of a general donation solution and Drupal/modules can benefit greatly from this - which is among the reasons why I started Donorge: anyone can benefit from using it.
Would like to help with project| groupware
I would like to help the work on project(management?)/groupware. I'm a bit overloaded, so I stopped the events/calendar/... modules, but some improvements to core could be nessasry. Count me in as help
Drupal fundraising
Note: I am 'lapurd', I changed my nick to CPlanken.
About the fundraising, 'Drupal' should understand my position on this. Donorge is all about donations in general, but optimized for free/open software. One important value of Donorge is that projects can show how they relate. So for example; all visitors would see that Donorge _depends_ on Drupal, in turn Drupal depends on other projects and so forth and so forth. This relational principle applies to _all software_ and _any project_ and all can show and tell about their own relations from their perspective with Donorge. I have friends who manage other open source projects themselves and Donorge is designed effectively so that all who use Donorge for donations share the same benefits from using it for donations. Donorge, as such, is about helping each other with donations and is to (under the GPL) develop that interest.
What this would mean practically for Drupal, is that Drupal could simply use Donorge for their donations and benefit from all practical advantages of using Donorge for this. Drupal would simply create a Drupal item on Donorge and it could then receive donations via Donorge. Drupal would then simply also be able to generate a donation button for the Drupal site. I do plan to later create a dedicated module for Drupal so that items using Donorge for donations which also use a site based on Drupal, can implement certain features (connected to their item on Donorge) into their site, but Donorge at it's current state is too young an undertaking for me to focus on this.
So that is what Donorge can do in relation to fundraising for Drupal; be a GPL based service (based on Drupal) which is designed to maximize the ability and effectiveness for donations towards Drupal and effectively anything using it for donations. Donorge will get more features over time that will _all_ act in the interest of donations and fundraising in general. You can already explore all current working features by creating a test account on the test site and safely do fake test donations to see what features Donorge offers so far ( http://testing.donorge.org ) The ability to post content and replies was delayed, because only the current Drupal 4.5.0 offers the functionality I was looking for. (b.t.w. Donorge now runs on Drupal 4.5.0)
For people who consider my post an 'advertisement' or 'commercial break', please realize that Donorge is something I have worked very very hard for well over a year on (in isolation), all in the base interest of getting a better donation solution for free/open software and beyond (I wanted working code before going more public). Donorge is GPL for well principled reasons and Donorge really acts out of donation interest like no other donation solution can offer at this moment.
In all this context, it actually puts Drupal in yet another special position and actually at the very core of it, ponder your mind about that for a moment. The strongest point about Donorge for Drupal is that it works as a dedicated service for anybody and anything, whereas a donation module for Drupal would only work inside Drupal frameworks and face many limitations in on-line donations. A dedicated GPL based donation service based on Drupal is what I considered the best thing I could offer Drupal and free software, that is why I do this, this is how I give back but not only to Drupal, but thanks _to_ Drupal. For more information on Donorge in relation to free/open software, see http://testing.donorge.org/d_content/info_os
Donorge is about helping each other on a fundamental supportive level going beyond software alone..and Drupal and the freedoms connected to the GPL allowed the realization of this so far!
I looked at Donurge
Looks interesting. Along with the whole "depends on", it could mean that people could donate to individual modules as well (which in turn "depend on" Drupal).
Theme and a How To
I intend to contribute a few simple theme's and a quick and dirty what to do now that Drupal is installed.
The few theme's are based on my need to make a few site's look individual and I finally understand how to make theme's with xTemplate. (it turn's out to not to be as difficult as I was making it out to be). I will simply do a generic 'Drupal' color scheme version. I will probably give a shot with some simple ones from phpTemplate too, but I can't consistently make it work.
There are often posts along the line's of "I installed Drupal, now what?' so I am going to expand a little on one of my posts (http://drupal.org/node/11410#comment-17623) to someone. I have to build a demo site to try and convince someone of the joys of a CMS site over a static content site maintained with Front Page. I intend to takes notes while doing so and post a write up. Essentially, 'So, now you've installed Drupal, download these modules, do this, this and this. There is your test site that is capable of this'.
I will also update this as needed (http://drupal.org/node/9407)
I have never been able to get this to work (http://drupal.org/node/3854) but I am going to try again this go around.
-sp
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
We also should review the use
We also should review the user module. It needs an overhaul.
Several modules also still use a lengthy _page function. Those should be broken up.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
--
Drupal services
My Drupal services