[drupal-devel] DrupalForge?

Dries Buytaert dries at buytaert.net
Mon Apr 25 07:14:44 UTC 2005


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 mailing list