[drupal-devel] CivicSpace development moving to Drupal
A couple things have become obvious to those of us working at CivicSpace: 1. We shouldn't be maintaining a development community. 2. We have been trying to maintain a development community. That means people who want to help out with CivicSpace will have to get on Drupal.org sooner or later. That is okay, every serious CivicSpace developer has done that anyway. This should be relatively straightforward: - All modules which are not in contrib should be in contrib. - All modules which don't have an associated project will have to get one. - Our issue tracker becomes a search over the issue tracker for the modules we include in CivicSpace. - Anyone who wants a sandbox or something else will have to go to Drupal. These things are being integrated into our development cycle soon. The overall status of our development (including moving to 4.6), can be found at http://civicspacelabs.org/home/developers/roadmap. There are a few things I could use some advice about: - Bug fix fridays in the Drupal community. The simple explanation is that Zack and I come up with a list of bugs to fix every Thursday, tell the CivicSpace developers mailing list about them, and bug assignments are made at a set time in an IRC room Which IRC room should be used, #drupal-bugfixday? Anyone else want to do this as well? - To properly release the configure [1] module it will need about 2/3 of the code pushed into individual modules using a new hook. We should have a debate about this going into Drupal core at some point. It could easily live as a contrib module, but I think we need to take a step back and think about how module installation works. - The contact [2] module. It has a naming collision, a replacement coming in some number of monthsi (CiviCRM), and hasn't had any non-bugfix updates since Drupal 4.4. This code isn't up to Drupal standards and shouldn't need to be updated, assuming CiviCRM works. - The contact module uses the forms [3] module. IMO, the forms module needs to be replaced with a core API based upon the admin-configurable forms in flexinode and profile modules. Contact uses an old version of forms module before some API changes; I like the changess, but haven't had the time to rewrite and retest contact module. - Survey [4] is forked because it has to work with the forms module we are using. And we haven't really gotten a good idea of how we expect people will want to use survey in the context of a CivicSpace site. - Our node_import [5] module is heavily forked. Things will get worse before they get better with the coming of CCK. This is something we can get working on 4.6, but we don't haven't been dedicating much resources to this module. - Install.php [6] is a heavily branded and Postgres incompatible moving target. Who is interested in helping get this into Drupal? I know people who want to make Drupal easier to install are out there. - We want to know when 4.6.0 final will be released. Yeah, I know, it is ready when it is ready and review issues and test it to make it go faster. Notes 1. Configure is a wizard to walk through the basic configurations needed to get a site running. 2. Contact keeps data from user registrations, mailing list sign ups, and data entry in a central location. 3. Forms provides an API for modules to maintain admin-configured forms. 4. Survey creates simple surveys for data collection. 5. Node_import imports CSV files as nodes. 6. Install.php loads table definitions into an SQL database and writes conf.php (yes, it is 4.5.x code right now). (This email will be cross posted to my blog at http://civicspacelabs.org/home/blog/71) -Neil Drumm Lead developer, CivicSpaceLabs.org
On Mar 15, 2005, at 8:49 PM, neil@civicspacelabs.org wrote:
A couple things have become obvious to those of us working at CivicSpace:
1. We shouldn't be maintaining a development community. 2. We have been trying to maintain a development community.
That means people who want to help out with CivicSpace will have to get on Drupal.org sooner or later. That is okay, every serious CivicSpace developer has done that anyway.
this is great news Neil. I'm sure this wasn't an easy decision to take. dries offerred at one time to give a branch to Civicspace at cvs.drupal.org. that might come in handy one day. the todo list seems long and painful, but we'll get through it. i think you need to speak with the maintainers of all these modules and convince them to do what you need because we all want Civicspace to keep on kicking ass. i suggest using #drupal for bug fixing discussions.
On Tue, Mar 15, 2005 at 10:36:58PM -0500, Moshe Weitzman wrote:
the todo list seems long and painful, but we'll get through it. i think you need to speak with the maintainers of all these modules and convince them to do what you need because we all want Civicspace to keep on kicking ass.
How about node_import module? I know it is a bit overengineered and we are importing to a moving target (CCK-related development). Having a UI to replace "make sure you have the right columns in your CSV" should be really nice. -Neil
On Tue, 15 Mar 2005 neil@civicspacelabs.org wrote: [good news]
There are a few things I could use some advice about:
- Bug fix fridays in the Drupal community. The simple explanation is that Zack and I come up with a list of bugs to fix every Thursday, tell the CivicSpace developers mailing list about them, and bug assignments are made at a set time in an IRC room Which IRC room should be used, #drupal-bugfixday? Anyone else want to do this as well?
I have told Dries somewhere between FOSDEM and Antwerp that I'd like to see that he'd assign bugs to people. An advantage might be that those bugs would a) get a patch sooner and b) that patch would be committted sooner to cvs because Dries c) cares about that bug and d) would maybe give some hints about the sort of solution he'd like to see.
- To properly release the configure [1] module it will need about 2/3 of the code pushed into individual modules using a new hook. We should have a debate about this going into Drupal core at some point. It could easily live as a contrib module, but I think we need to take a step back and think about how module installation works.
Can this get combined with Adrian's installer?
[forked modules]
There are IMHO several things you can do: - try to get the maintainer of a corresponding Drupal module to accept your patches - continue to maintain those (few) modules on csl. - try to get some stuff in core. forms.module sounds as if there might be a connection to CCK.
- Install.php [6] is a heavily branded and Postgres incompatible moving target. Who is interested in helping get this into Drupal? I know people who want to make Drupal easier to install are out there.
Typically those people wouldn't be able to help you much. ;^) As sceptical as I am about installers I sure do not want there to be two of them. Adrian has been working on one for bryght and said he'd contribute that back to Drupal.
- We want to know when 4.6.0 final will be released. Yeah, I know, it is ready when it is ready and review issues and test it to make it go faster.
Well, the 15th has passed. Dries got his new laptop so the cvs commit rate should increase again. I am not sure a 1st of April release is a good idea, though. Maybe we should draft a list of issues that need fixing before the release. Cheers, Gerhard
On 16 Mar 2005, at 06:14, Gerhard Killesreiter wrote:
- We want to know when 4.6.0 final will be released. Yeah, I know, it is ready when it is ready and review issues and test it to make it go faster.
Well, the 15th has passed. Dries got his new laptop so the cvs commit rate should increase again. I am not sure a 1st of April release is a good idea, though.
Bear with me as I get everything installed on my new laptop. Switching from Linux to Mac is quite a change. Next on my TODO list are installing PHP5, MySQL and Apache. I should have everything up and running in a day or two. Note that I'll be away from the keyboard from March 25 to April 2 so an April 1st release is not an option. I think I prefer to be around when Drupal 4.6 is released so I'd like to release the first week of April. Regardless, last minute improvements should go in before March 25. During my absence there won't be many commits (if any), and upon my return I will only consider critical bug fixes. If everything works out, that is. :) Only a handful of contributions have been branched, so that leaves the maintainers some extra time to get their code working with Drupal 4.6. It is time to move on, to open up CVS for fresh development, and to embrace the CivicSpace initiative. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
Bear with me as I get everything installed on my new laptop. Switching from Linux to Mac is quite a change. Next on my TODO list are installing PHP5, MySQL and Apache. I should have everything up and running in a day or two.
This may help :) http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/powerpc/rc2/sarge-po...
On Wed, Mar 16, 2005 at 06:14:52AM +0100, Gerhard Killesreiter wrote:
- To properly release the configure [1] module it will need about 2/3 of the code pushed into individual modules using a new hook. We should have a debate about this going into Drupal core at some point. It could easily live as a contrib module, but I think we need to take a step back and think about how module installation works.
Can this get combined with Adrian's installer?
The wizard.inc file the configure module uses was origionally Adrian's code. I would make a diff and look through what we changed, but I have no idea where a copy from Adrian lives. I estimate that it is less than 10 changed lines. -Neil
On 16 Mar 2005, at 10:25 PM, neil@civicspacelabs.org wrote:
On Wed, Mar 16, 2005 at 06:14:52AM +0100, Gerhard Killesreiter wrote:
- To properly release the configure [1] module it will need about 2/3 of the code pushed into individual modules using a new hook. We should have a debate about this going into Drupal core at some point. It could easily live as a contrib module, but I think we need to take a step back and think about how module installation works.
Can this get combined with Adrian's installer?
The wizard.inc file the configure module uses was origionally Adrian's code. I would make a diff and look through what we changed, but I have no idea where a copy from Adrian lives. I estimate that it is less than 10 changed lines.
Civicspace's installer forms part of my install system plans. Perhaps we should schedule an install system irc meeting soon ? -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 16 Mar 2005, at 10:25 PM, neil@civicspacelabs.org wrote:
On Wed, Mar 16, 2005 at 06:14:52AM +0100, Gerhard Killesreiter wrote:
- To properly release the configure [1] module it will need about 2/3 of the code pushed into individual modules using a new hook. We should have a debate about this going into Drupal core at some point. It could easily live as a contrib module, but I think we need to take a step back and think about how module installation works.
Can this get combined with Adrian's installer?
The wizard.inc file the configure module uses was origionally Adrian's code. I would make a diff and look through what we changed, but I have no idea where a copy from Adrian lives. I estimate that it is less than 10 changed lines.
Civicspace's installer forms part of my install system plans. Perhaps we should schedule an install system irc meeting soon ? -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 16-Mar-05, at 12:14 AM, Gerhard Killesreiter wrote:
On Tue, 15 Mar 2005 neil@civicspacelabs.org wrote:
[good news]
There are a few things I could use some advice about:
- Bug fix fridays in the Drupal community. The simple explanation is that Zack and I come up with a list of bugs to fix every Thursday, tell the CivicSpace developers mailing list about them, and bug assignments are made at a set time in an IRC room Which IRC room should be used, #drupal-bugfixday? Anyone else want to do this as well?
I have told Dries somewhere between FOSDEM and Antwerp that I'd like to see that he'd assign bugs to people. An advantage might be that those bugs would a) get a patch sooner and b) that patch would be committted sooner to cvs because Dries c) cares about that bug and d) would maybe give some hints about the sort of solution he'd like to see.
+1 (with a big "+"). Might even be better (even if as a longer term solution) if there was a way to have issues for "components" automatically assigned to folks . I know I know ... "feel free to patch project.module". But, personally, it would speed response up greatly if, say, all image.inc issues automatically showed up in "my issues" (and consequently in my issue feed). I mean, I realize this delegation sorta happens now informally... but I also know I've been asked to have a look at patch X and if I don't do it right away (or make a note to do it later) I forget. -- James Walker :: http://www.walkah.net/
Another big +1 Op donderdag 24 maart 2005 06:52, schreef James Walker:
On 16-Mar-05, at 12:14 AM, Gerhard Killesreiter wrote: +1 (with a big "+"). Might even be better (even if as a longer term solution) if there was a way to have issues for "components" automatically assigned to folks . I know I know ... "feel free to patch project.module". But, personally, it would speed response up greatly if, say, all image.inc issues automatically showed up in "my issues" (and consequently in my issue feed).
I predict that if there is one, lets say, RSS feed guy (or gal), then automagically some sort of group will arise around her (or him). I beleive that with assigning bugs, you create gurus. And with creating gurus you create groups. And with that people (yep, those) will see that the Drupal Model actually works very well, instead of just having to beleive us :) If you can go directly to the Feed Guru with YourBrilliantRSSPAtch, and he (or she) rutns it down, then * Dries does not have to bother * YourBrilliantRSSPAtch was turned down for a good reason. One that you will be able to see very well, since it was turned down by a SQL guru (not That i am saying that Dries would not be competent for this, its just that a lot of people seem to think so) * The SQL guru will be able to coordinate much better when and how YourBrilliantRSSPAtch could go in. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Thu, 24 Mar 2005, James Walker wrote:
On 16-Mar-05, at 12:14 AM, Gerhard Killesreiter wrote:
I have told Dries somewhere between FOSDEM and Antwerp that I'd like to see that he'd assign bugs to people. An advantage might be that those bugs would a) get a patch sooner and b) that patch would be committted sooner to cvs because Dries c) cares about that bug and d) would maybe give some hints about the sort of solution he'd like to see.
+1 (with a big "+").
Thanks. I'd really like to see the Drupal project advance a bit faster than it does now. Currently, I am often not sure if it is worth my time to work on a specific bug/feature as I have not much of an idea if (and when!) it will make it to core. I guess there are more people like me.
Might even be better (even if as a longer term solution) if there was a way to have issues for "components" automatically assigned to folks.
Would be nice, yes.
I know I know ... "feel free to patch project.module". But,
:)
personally, it would speed response up greatly if, say, all image.inc issues automatically showed up in "my issues" (and consequently in my issue feed).
Well, you can subscribe to the Drupal project and get all those things mailed. Some procmail magic might even sort the image.inc mails into the right mailbox. I know, not really what you want.
I mean, I realize this delegation sorta happens now informally... but I also know I've been asked to have a look at patch X and if I don't do it right away (or make a note to do it later) I forget.
Yeah, like the message_access() patch. ;) And no, I don't think I'd like to introduce the kind of bureaucrazy that Nedjo proposed. ;) Cheers, Gerhard
On 24 Mar 2005, at 11:40, Gerhard Killesreiter wrote:
Thanks. I'd really like to see the Drupal project advance a bit faster than it does now.
Currently, I am often not sure if it is worth my time to work on a specific bug/feature as I have not much of an idea if (and when!) it will make it to core. I guess there are more people like me.
I'm compiling a detailed list of things I believe are core-worthy and which I'd like to see included or worked on. I'll share this list as soon as it's ready. At the top of my head, in no particular order and lacking details: 1. Workflow actions (and e-mail subscriptions/notifications in particular) 2. Improved node submission form 3. Profile fields per role 4. Blocks visibility per role 5. phpTemplate 6. Better link management (node links + menu links) 7. Folksonomies and taxonomy improvements 8. CCK 9. Improved administration structure, visual distinction, intuitive placement of settings 10. Improved versioning 11. Loose caching 12. Better blog.module 13. Better archive.module 14. Contact module extension to let you contact groups of people. 15. USABILITY IMPROVEMENTS 16. Improved 'my account' page. 17. One node-level permissions scheme (taxonomy-role?) 18. Better file handling/serving (permissions) 19. Misc. aggregator improvements -- Dries Buytaert :: http://www.buytaert.net/
On Thu, 24 Mar 2005, Dries Buytaert wrote:
On 24 Mar 2005, at 11:40, Gerhard Killesreiter wrote:
Thanks. I'd really like to see the Drupal project advance a bit faster than it does now.
Currently, I am often not sure if it is worth my time to work on a specific bug/feature as I have not much of an idea if (and when!) it will make it to core. I guess there are more people like me.
I'm compiling a detailed list of things I believe are core-worthy and which I'd like to see included or worked on. I'll share this list as soon as it's ready. At the top of my head, in no particular order and lacking details:
Yay! I'll remove the items I am not interested in. The remaining list will show which areas I am interested in and hope to join/lead an effort to get that into core. I suggest that others do the same and we compile a list.
1. Workflow actions (and e-mail subscriptions/notifications in particular) 3. Profile fields per role 7. Folksonomies and taxonomy improvements 8. CCK
9. Improved administration structure, visual distinction, intuitive placement of settings
Maybe we can finally agree that it is a Bad Thing(tm) that menu items move when translated...
10. Improved versioning
*g*
14. Contact module extension to let you contact groups of people.
Moshe has some code for contacting groups of people in og.module. I borrowed that code for groups.module and extended it to honour the "contact" preference of the individual users so that users can disable those group mails.
16. Improved 'my account' page.
What kind of improvements?
17. One node-level permissions scheme (taxonomy-role?)
There are currently taxonomy_access and node_privacy_byrole. taxonomy_access could use some codeing style cleanup. I have used a previous version of taxonomy_access and do like it.
18. Better file handling/serving (permissions)
Yeah, the current private download is sub-optimal as the whole Drupal is loaded per private file, ie if you have a user listing with 10 user pictures and use privatze downloads, Drupal will be executed 11 times... I've investigated to use an Apache module for this. The result isn't quite clear atm (and not usable for most users I know). There could be a small files.php file which does the file serving. This depends on the split up of the .inc files in files that contain code and files that execute it which I presented a short while ago. Cheers, Gerhard
9. Improved administration structure, visual distinction, intuitive placement of settings
Maybe we can finally agree that it is a Bad Thing(tm) that menu items move when translated...
No we cannot agree on this. I would not like to see my menu items ordered randomly on my hungarian sites... Goba
On Thu, 24 Mar 2005, Gabor Hojtsy wrote:
9. Improved administration structure, visual distinction, intuitive placement of settings
Maybe we can finally agree that it is a Bad Thing(tm) that menu items move when translated...
No we cannot agree on this. I would not like to see my menu items ordered randomly on my hungarian sites...
Now you are confusing me. I think you should agree with me, because with my proposal we would: - find a way in which the links should be ordered that provides best usability - keep that order after translations. That wouldn't be random ordering at all. What we currently have is random ordering. It depends on the chosen langauage and the way the menu items are translated. Cheers, Gerhard
9. Improved administration structure, visual distinction, intuitive placement of settings
Maybe we can finally agree that it is a Bad Thing(tm) that menu items move when translated...
No we cannot agree on this. I would not like to see my menu items ordered randomly on my hungarian sites...
Now you are confusing me. I think you should agree with me, because with my proposal we would:
- find a way in which the links should be ordered that provides best usability - keep that order after translations.
That wouldn't be random ordering at all. What we currently have is random ordering. It depends on the chosen langauage and the way the menu items are translated.
I might be able to agree, but what do you do with arbitrary installed modules injecting new menu items inbetween existing ones? Goba
Op donderdag 24 maart 2005 13:56, schreef Gabor Hojtsy:
No we cannot agree on this. I would not like to see my menu items ordered randomly on my hungarian sites...
+1 from me. When changing to Dutch, I Love having to search for my menuitems every time :) Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Hi, Op donderdag 24 maart 2005 13:18, schreef Dries Buytaert:
1. Workflow actions (and e-mail subscriptions/notifications in particular) 2. Improved node submission form 3. Profile fields per role 4. Blocks visibility per role 5. phpTemplate 6. Better link management (node links + menu links) 7. Folksonomies and taxonomy improvements 8. CCK 9. Improved administration structure, visual distinction, intuitive placement of settings 10. Improved versioning 11. Loose caching 12. Better blog.module 13. Better archive.module 14. Contact module extension to let you contact groups of people. 15. USABILITY IMPROVEMENTS 16. Improved 'my account' page. 17. One node-level permissions scheme (taxonomy-role?) 18. Better file handling/serving (permissions) 19. Misc. aggregator improvements
For 4.5 I tried to make some sort of roadmap, with groups. Can we use this list for an improved roadmap? Also, since I do not (plan to) use project module, i want to ask, no beg, someone who does have it installed, to look into this feature: Tasks, bugs and features that are: 1) member of Drupal project, 2) marked critical 3) have a developer assigned to 'em 4) have status of either "active", "patch", "closed" or "fixed". But not when wontfix, by design or duplicate. 5) have a flag "roadmap" set, should show Up in a list called "Roadmap". That list will show: * Todo, when the status is "active" * Work in progress, when status is "patch", or when issue has comments. * Done when status is "fixed" or "closed". Maintaining a roadmap by hand, like i did last round is just too much work, and is never up-to-date. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
What is meant by #10, Improved Versioning? I have some ideas I would like to implement in the area of versioning, but I wonder if they are at all related to what Dries has in mind. -- Chris Johnson (irc: cxj)
On Thu, 24 Mar 2005, Chris Johnson wrote:
What is meant by #10, Improved Versioning? I have some ideas I would like to implement in the area of versioning, but I wonder if they are at all related to what Dries has in mind.
I think that Dries was referring to my revisions patch. http://drupal.org/node/7582 I'd welcome suggestions (but would prefer to see land this patch first). Cheers, Gerhard
Dries, I'm really excited by this whole list! (I would add forum improvements as well, but other than that, it looks good). You should know that I'm endeavoring to make a really cool project module for Spread Firefox v2 which basically aims to combine 43things.com with Basecamp-like workspaces. I think this would be extremely useful for Drupal & CivicSpace since it would allow people to: 1. find new projects 2. suggest new projects 3. create new projects and get volunteers 4. have instant workspaces (blog, forums, issue tracking, member tracking, etc) The goal is to imitate SourceForge but do it right and make it very simply to get involved or simply track a project. I'll be mockup up workflows and UI stuff in the coming week(s). I have 20 or so people ready on the SFX side to work on this and are already developing their own requirements and ideas. Ideally this could be a really excellent project for us to collaborate on. If you're interested, you can see some of the very early initial ideas for the SFX redesign here: http://www.flickr.com/photos/factoryjoe/sets/135075/ Thoughts & ideas welcome! Chris On Thu, 24 Mar 2005 13:18:34 +0100, Dries Buytaert <dries@buytaert.net> wrote:
On 24 Mar 2005, at 11:40, Gerhard Killesreiter wrote:
Thanks. I'd really like to see the Drupal project advance a bit faster than it does now.
Currently, I am often not sure if it is worth my time to work on a specific bug/feature as I have not much of an idea if (and when!) it will make it to core. I guess there are more people like me.
I'm compiling a detailed list of things I believe are core-worthy and which I'd like to see included or worked on. I'll share this list as soon as it's ready. At the top of my head, in no particular order and lacking details:
1. Workflow actions (and e-mail subscriptions/notifications in particular) 2. Improved node submission form 3. Profile fields per role 4. Blocks visibility per role 5. phpTemplate 6. Better link management (node links + menu links) 7. Folksonomies and taxonomy improvements 8. CCK 9. Improved administration structure, visual distinction, intuitive placement of settings 10. Improved versioning 11. Loose caching 12. Better blog.module 13. Better archive.module 14. Contact module extension to let you contact groups of people. 15. USABILITY IMPROVEMENTS 16. Improved 'my account' page. 17. One node-level permissions scheme (taxonomy-role?) 18. Better file handling/serving (permissions) 19. Misc. aggregator improvements
-- Dries Buytaert :: http://www.buytaert.net/
Sounds great Chris. Your engineers might want to architect this using og.module (organic groups) as their basis for projects and workspaces. It supports al lot of what you are going to need public/private/moderated groups, group admins, access control, photo albums, group blogs, etc. It does not have strict project/ticketing yet. I'd be happy to help the SFX team if desired. -moshe Chris Messina wrote:
Dries,
I'm really excited by this whole list! (I would add forum improvements as well, but other than that, it looks good).
You should know that I'm endeavoring to make a really cool project module for Spread Firefox v2 which basically aims to combine 43things.com with Basecamp-like workspaces. I think this would be extremely useful for Drupal & CivicSpace since it would allow people to:
1. find new projects 2. suggest new projects 3. create new projects and get volunteers 4. have instant workspaces (blog, forums, issue tracking, member tracking, etc)
The goal is to imitate SourceForge but do it right and make it very simply to get involved or simply track a project. I'll be mockup up workflows and UI stuff in the coming week(s). I have 20 or so people ready on the SFX side to work on this and are already developing their own requirements and ideas. Ideally this could be a really excellent project for us to collaborate on.
If you're interested, you can see some of the very early initial ideas for the SFX redesign here:
http://www.flickr.com/photos/factoryjoe/sets/135075/
Thoughts & ideas welcome!
Chris
On Thu, 24 Mar 2005 13:18:34 +0100, Dries Buytaert <dries@buytaert.net> wrote:
On 24 Mar 2005, at 11:40, Gerhard Killesreiter wrote:
Thanks. I'd really like to see the Drupal project advance a bit faster than it does now.
Currently, I am often not sure if it is worth my time to work on a specific bug/feature as I have not much of an idea if (and when!) it will make it to core. I guess there are more people like me.
I'm compiling a detailed list of things I believe are core-worthy and which I'd like to see included or worked on. I'll share this list as soon as it's ready. At the top of my head, in no particular order and lacking details:
1. Workflow actions (and e-mail subscriptions/notifications in particular) 2. Improved node submission form 3. Profile fields per role 4. Blocks visibility per role 5. phpTemplate 6. Better link management (node links + menu links) 7. Folksonomies and taxonomy improvements 8. CCK 9. Improved administration structure, visual distinction, intuitive placement of settings 10. Improved versioning 11. Loose caching 12. Better blog.module 13. Better archive.module 14. Contact module extension to let you contact groups of people. 15. USABILITY IMPROVEMENTS 16. Improved 'my account' page. 17. One node-level permissions scheme (taxonomy-role?) 18. Better file handling/serving (permissions) 19. Misc. aggregator improvements
-- Dries Buytaert :: http://www.buytaert.net/
Excellent. I'll get them to check it out ASAP. What's fairly ironic about this, is that if the module/functionality that I'm looking for existed, we could use it to build this module!! ;) Chris On Thu, 24 Mar 2005 14:14:33 -0500, Moshe Weitzman <weitzman@tejasa.com> wrote:
Sounds great Chris. Your engineers might want to architect this using og.module (organic groups) as their basis for projects and workspaces. It supports al lot of what you are going to need public/private/moderated groups, group admins, access control, photo albums, group blogs, etc. It does not have strict project/ticketing yet. I'd be happy to help the SFX team if desired.
-moshe
Chris Messina wrote:
Dries,
I'm really excited by this whole list! (I would add forum improvements as well, but other than that, it looks good).
You should know that I'm endeavoring to make a really cool project module for Spread Firefox v2 which basically aims to combine 43things.com with Basecamp-like workspaces. I think this would be extremely useful for Drupal & CivicSpace since it would allow people to:
1. find new projects 2. suggest new projects 3. create new projects and get volunteers 4. have instant workspaces (blog, forums, issue tracking, member tracking, etc)
The goal is to imitate SourceForge but do it right and make it very simply to get involved or simply track a project. I'll be mockup up workflows and UI stuff in the coming week(s). I have 20 or so people ready on the SFX side to work on this and are already developing their own requirements and ideas. Ideally this could be a really excellent project for us to collaborate on.
If you're interested, you can see some of the very early initial ideas for the SFX redesign here:
http://www.flickr.com/photos/factoryjoe/sets/135075/
Thoughts & ideas welcome!
Chris
On Thu, 24 Mar 2005 13:18:34 +0100, Dries Buytaert <dries@buytaert.net> wrote:
On 24 Mar 2005, at 11:40, Gerhard Killesreiter wrote:
Thanks. I'd really like to see the Drupal project advance a bit faster than it does now.
Currently, I am often not sure if it is worth my time to work on a specific bug/feature as I have not much of an idea if (and when!) it will make it to core. I guess there are more people like me.
I'm compiling a detailed list of things I believe are core-worthy and which I'd like to see included or worked on. I'll share this list as soon as it's ready. At the top of my head, in no particular order and lacking details:
1. Workflow actions (and e-mail subscriptions/notifications in particular) 2. Improved node submission form 3. Profile fields per role 4. Blocks visibility per role 5. phpTemplate 6. Better link management (node links + menu links) 7. Folksonomies and taxonomy improvements 8. CCK 9. Improved administration structure, visual distinction, intuitive placement of settings 10. Improved versioning 11. Loose caching 12. Better blog.module 13. Better archive.module 14. Contact module extension to let you contact groups of people. 15. USABILITY IMPROVEMENTS 16. Improved 'my account' page. 17. One node-level permissions scheme (taxonomy-role?) 18. Better file handling/serving (permissions) 19. Misc. aggregator improvements
-- Dries Buytaert :: http://www.buytaert.net/
not exactly what request, but can see all issues assigned to the projects you own on one page (see bottom) - http://drupal.org/project/user
On 16 Mar 2005, at 02:49, neil@civicspacelabs.org wrote:
This should be relatively straightforward:
- All modules which are not in contrib should be in contrib. - All modules which don't have an associated project will have to get one. - Our issue tracker becomes a search over the issue tracker for the modules we include in CivicSpace. - Anyone who wants a sandbox or something else will have to go to Drupal.
These things are being integrated into our development cycle soon. The overall status of our development (including moving to 4.6), can be found at http://civicspacelabs.org/home/developers/roadmap.
Great news, Neil.
There are a few things I could use some advice about:
- Bug fix fridays in the Drupal community. The simple explanation is that Zack and I come up with a list of bugs to fix every Thursday, tell the CivicSpace developers mailing list about them, and bug assignments are made at a set time in an IRC room Which IRC room should be used, #drupal-bugfixday? Anyone else want to do this as well?
I'm OK with that. Feel free to organize that, to announce it on drupal.org, etc. Is there anything you need to make this happen (eg. installing an event module on drupal.org)?
- The contact [2] module. It has a naming collision, a replacement coming in some number of monthsi (CiviCRM), and hasn't had any non-bugfix updates since Drupal 4.4. This code isn't up to Drupal standards and shouldn't need to be updated, assuming CiviCRM works.
I suggest you reserve the name crm.module. It shouldn't be too difficult to rename your existing contact module.
- The contact module uses the forms [3] module. IMO, the forms module needs to be replaced with a core API based upon the admin-configurable forms in flexinode and profile modules. Contact uses an old version of forms module before some API changes; I like the changess, but haven't had the time to rewrite and retest contact module.
This is of interest for the CCK and the profile modules. We can probably start working on that using the profile module and the contact module as a use-case. Some more thoughts: 1. The availability of the drupal.org infrastructure - and the CVS repositories in particular - will become increasingly important. Ditto for approving and managing CVS accounts. It might make sense to move the contributions repository to a dedicated machine. Like that, system administrators can be recruited to help administer CVS. Because the way CVS integrates into drupal.org, this might be a bit of a challenge. Anyway, food for thought. 2. We can create a 'Distribution vocabulary' and bind it to project issues. It lets you filter, track and syndicate CivicSpace related issues. It makes sense to invest in the project module a bit (e.g. and to look into Nedjo's project module patch). -- Dries Buytaert :: http://www.buytaert.net/
Wednesday, March 16, 2005, 9:46:34 AM, Dries Buytaert wrote:
1. The availability of the drupal.org infrastructure - and the CVS repositories in particular - will become increasingly important. Ditto for approving and managing CVS accounts. It might make sense to move the contributions repository to a dedicated machine. Like that, system administrators can be recruited to help administer CVS. Because the way CVS integrates into drupal.org, this might be a bit of a challenge. Anyway, food for thought.
I don't see fragmenting the cvs repos as necessary. There are plenty of other ways to go (restricted ftp access, chrooted accounts, online interface with backend scripts, etc). I am not 100% uptodate on how we handle new cvs accounts but from how it looks i could now automate it more with a few hours of work. Dries: I'll be in Belgium from monday next week so you can update me then over dinner ;)
2. We can create a 'Distribution vocabulary' and bind it to project issues. It lets you filter, track and syndicate CivicSpace related issues. It makes sense to invest in the project module a bit (e.g. and to look into Nedjo's project module patch).
The project module already has integration with taxonomy (just no search interface since I got frustrated with taxonomy.module when I tried). Issues should be taxonomy enabled as well, or its a quick addition to the _form(), but again search is non existent. The only challenge would be that you cant change the taxonomy in updates, just when initially posted, again something that can probably be added. Releases are not nodes and hence can not be taxonomized without applying some of the patches that make taxonomy more generic. -- Kjartan <kjartan@drupal.org> :: "Life consists not in holding good cards but in playing those you hold well." - Josh Billings
On Wed, Mar 16, 2005 at 09:46:34AM +0100, Dries Buytaert wrote:
2. We can create a 'Distribution vocabulary' and bind it to project issues. It lets you filter, track and syndicate CivicSpace related issues. It makes sense to invest in the project module a bit (e.g. and to look into Nedjo's project module patch).
This will make my life a bit easier. I have already tried to select only the CivicSpace modules in that little select box on the advanced search page and failed twice. -Neil
participants (12)
-
Adrian Rossouw -
Bèr Kessels -
Chris Johnson -
Chris Messina -
Curtis Nelson -
Dries Buytaert -
Gabor Hojtsy -
Gerhard Killesreiter -
James Walker -
Kjartan Mannes -
Moshe Weitzman -
neil＠civicspacelabs.org