dan at civicactions.com
Mon Apr 25 14:45:44 UTC 2005
I don't want to keep talking because I feel I'm violating the
silver/gold business (which is a good rule of thumb :) ). Don't get me
wrong on my comments, my point really is that with better packaging we
would get more traction, which gives us more people, which gives us more
developers which then gets us more coders (or talkers.... depending :)
). Anyway I was really struck by what was said re: the Project module:
The project module has been making progress, and still is. The past
three months I added (i) CVS integration, (ii) compilation of a per
project developer lists and (iii) automated code reviews/reports.
Furthermore, we have nedjo's patch waiting to be tested and it looks
like Steven and Ber began investigating some of the imminent usability
issues. At the same time, we encourage people to make the project
module more generic.
I went to the project page for Project and got -
This module enables teams to track outstanding items which need
resolution. It provides e-mail notifications to members about updates to
items. Similar to many issue tracking systems.
I'm not criticising - just pointing out that there is a huge knowledge
gap - if someone is coming from the outside and evaluating then they are
going to miss a huge gold-mine of functionality. Anyway - at this point
I'm hoping that I will come back later with some concrete deliverables
to help out. Meanwhile back to the silver mines.
> On 24 Apr 2005, at 22:52, Dan Robinson wrote:
>>>> 2) Their admin panel gives great demo.
>>> Maybe we could have a pseudo-demo. By pseudo-demo I mean that we could
>>> have a html dump of an admin interface without any working forms. This
>>> would save us from needing another database etc. but would people allow
>>> to have a look behind the scenes. People who'd like to have a real demo
>>> site could go to opensourcecms or what was it called. In any case we
>>> should have a prominent link to oscms.
> Note that Drupal's project page on drupal.org has a "demo link" that
> points to the demo at opensourcecms.com.
> In other words, there is a demo, although it might not be very visible.
>>>> I completely understand the "eat your own dogfood approach". I also
>>>> understand the "focus, focus, focus" approach as well as the "do what
>>>> you do best" approach. I think that the project module is a great
>>>> example. My experience with the project module (for bug/feature
>>>> tracking) is in comparison with bugzilla. Bugzilla looks and feels
>>>> really terrible - however it really gets the job done. What is the
>>>> relative importance in having a great drupal project module to other
>>>> important features? How is this communicated within the community?
>>> The project.module isn't bad at doing what it was designed for. Quite
>>> the contrary. Buit since Drupal grows at a rather steep rate we need to
>>> improve it.
> The project module has been making progress, and still is. The past
> three months I added (i) CVS integration, (ii) compilation of a per
> project developer lists and (iii) automated code reviews/reports.
> Furthermore, we have nedjo's patch waiting to be tested and it looks
> like Steven and Ber began investigating some of the imminent usability
> issues. At the same time, we encourage people to make the project
> module more generic.
>>>> What is more of a motivation - saying that we're using something of
>>>> inferior quality and hoping that the pain of using it will encourage
>>>> developers to meet the challenge?
> I can't speak for others but I'd rather spend my time improving the
> project module than writing conversion scripts or maintaining a
> separate project site. Furthermore, I'm convinced that the final
> outcome will be better than using Bugzilla or SourceForge. Call me
> stupid, but if I wasn't convinced I/we could make a better a product
> than PHP-Nuke, ThatWare, Scoop or Slash, we wouldn't be working on
> Drupal to begin with. Sometimes it takes some persistence.
>>>> Anyway - interesting discussion.
>>> According to the "talk is silver, code is gold" mantra we should get
>>> some code in the project module just now...
>>> Things to consider:
>>> - Would it make sense to use actions/workflow.module for it?
>>> - Why does it need to have its own comment stuff?
>>> Probably in order to have the extended form that we use.
>>> This could be a reason to apply the commentapi patch to Drupal and go
>>> from there to removing the extra comment handling in project module.
>>> - Remove hardcoded status codes.
>>> - Introduce better mailed issues. Issues should be mailed similar to
>>> how mailman mails digests.
> Great start! :-)
> Dries Buytaert :: http://www.buytaert.net/
More information about the drupal-devel