Forum OpenACS Improvement Proposals (TIPs): TIP #28: (Approved) Create package-specific enhancement lists under

1: TIP #28: (Approved) Create package-specific enhancement lists under

Posted by Dirk Gomez on 11/12/03 06:06 PM

Proposal

Create package-specific enhancement lists under http://openacs.org/projects/.

Reason

People ask very frequently whether a new feature is planned for a package or what kind of work in general is going on for a package. For example here http://openacs.org/forums/message-view?message_id=142461

The place for new features to be requested actually is the bugtracker, but it seems that bugtracker listings are not concise enough, hence my idea to create a one-stop page for each package that'll list future enhancements.

Here's an example for calendar:

------ SNIP HERE ------

Calendar Development Roadmap

(Author: Dirk Gomez)

For the 5.1 release I am planning to do these things:

Cleaning up code
ical integration
Plotting out a new datamodel
bar
...

5.2 will bring the new datamodel which will help integrating time-based events into calendar views. Blabla

------ SNIP HERE ------

It would be great to show bugtracker tickets, todos, and enhancements here for this particular package via an include tag.

2: Re: Create package-specific enhancement lists under (response to 1)

Posted by Jade Rubick on 11/12/03 09:34 PM

Sounds like a good idea to me. The package owner would then have an ETP instance, right?

3: Re: Create package-specific enhancement lists under (response to 1)

Posted by Rocael Hernández Rizzardini on 11/12/03 09:51 PM

ETP admin permission to the specific package page ....

4: Re: Create package-specific enhancement lists under (response to 1)

Posted by Dirk Gomez on 11/12/03 11:04 PM

Yes, one (or more) people would maintain etp packages and get the necessary permissions.

5: Re: TIP #28: Create package-specific enhancement lists under (supported) (response to 1)

Posted by Malte Sussdorff on 11/13/03 08:44 AM

I support this idea, if multiple people get access to maintain each page, depending on their involvement with the package.

6: Re: TIP #28: Create package-specific enhancement lists under (response to 1)

Posted by Joel Aufrecht on 11/13/03 09:49 AM

Why use an ETP, when all of the content is list entries? Lists of problems, lists of to-dos. Each item has text descriptions, current status, planned target for fix, owner ... Why not just use the bug system? Then the home page for each module is basically an auto-generated page, and if we want a running commentary we could make it a two-column page, with a blog on one side and the bug tracker list on the other.

7: Re: TIP #28: Create package-specific enhancement lists under (response to 6)

Posted by Dirk Gomez on 11/13/03 10:41 AM

Great proposal, Joel. That avoids duplicated and thus information that will get stale over time.

I volunteer for programming the include snippet for bugtracker.

8: Re: TIP #28: Create package-specific enhancement lists under (response to 6)

Posted by Malte Sussdorff on 11/13/03 01:01 PM

Just have a look at the survey situation. Getting this specification in ONE file is just to much to read in a bug-tracker. If you talk about creating bugs for each of the items, then this might make sense, but again, how would we generate an overview page? Display all tickets associated with the package?

So not sure how this helps collaboration on the status and specifications of packages.

9: Re: TIP #28: Create package-specific enhancement lists under (response to 1)

Posted by Dirk Gomez on 11/13/03 05:30 PM

Yes, display the tickets' headlines in one snippet and then a blog - that has been my appraising understanding of Joel's proposal.

10: Re: TIP #28: Create package-specific enhancement lists under (response to 1)

Posted by Dirk Gomez on 11/14/03 12:39 PM

LEt's go back to my proposal: to create a concise and succinct listing of to-be-expected features. How it is done in detail doesn't matter too much to me. Eventually the best-maintained package page will draw most attention, the maintainers will get most patches, proposals, and funding.

Shouldn't the TIP forum be a voting forum and if there is a YES on a particular proposal its details will be discussed elsewhere?

Currently the TIP process is very ineffective: we seem to never achieve results.

11: Re: TIP #28: Approved by Dave Bauer (response to 1)

Posted by Dave Bauer on 11/14/03 03:13 PM

This is a good idea. As we already have ETP installed there, we can add a subtopic for each package so that permissions can be granted for each package seperately.

Anyone who is working on a package should be given access to edit the page.

12: Re: TIP #28: Approved by Dave Bauer (response to 11)

Posted by Jeff Davis on 11/14/03 08:48 PM

I am not sure we really need TIPs for site content things like this since its mostly not a technical issue for OpenACS per se. I basically think that if someone want to take responsibility for implementing the functionality on openacs.org and it gets used then great.

We don't use openacs.org enough as a test bed for new functionality (I feel like the biggest improvements in forums, bug tracker, notifications, etc came as a consequence of all of us using the packages). If you want to implement something you think would be useful on openacs.org go ahead (the stuff Bart has done with irc logging and his new cvs frontend to cvsweb/viewcvs are good examples of this).

Its also why it's so important to get openacs.org back to the head. We are not really using the current head code here and I think the additional scrutiny and having to eat our own dogfood (frankly bad tasting in some cases) would translate to a much improved toolkit. Nothing else improves things faster than having us all using the code.

Things that might be great to have on openacs.org include wp, Jade's project manager, Dave's wiki stuff, project blogs, my cvs browser (integrated with bug tracker would be even better), photobook (once there is a postgres port), and many more that I can't think of off the top of my head. I would love to see an "Open Source Intranet" that helped bring together the things Dirk and Malte (and Joel) have mentioned in one place, consolidating blogs, bug tracker, forums, etc and making it all much more useful in keeping people informed, coordinating work, and ultimately making it a testimony to the power of the toolkit for building communities.

13: Re: TIP #28: Approved by Dave Bauer (response to 12)

Posted by Carl Robert Blesius on 11/14/03 08:57 PM

Amen Jeff, amen.

14: Re: TIP #28: Create package-specific enhancement lists under (response to 1)

Posted by Lars Pind on 11/15/03 12:45 AM

Yeah. Go ahead. Approved. Though no TIP really required.

My only concern is stale info, which we've seen enough of already.

/Lars

15: Re: TIP #28: (Approved) Create package-specific enhancement lists under (response to 1)

Posted by Bruno Mattarollo on 12/27/03 01:12 AM

Hey Dirk, how far have you gone into the iCal integration? I am starting to write some code to try to "export" to iCal using as a base the outlook procs ... doing this in my spare time so going quite slowly (haven't done any OpenACS work in quite a while) but getting there ;)

My idea is to have a library to export (just formatting one calendar into iCal RFC's 2445) and then be able to upload from iCal (apple's Calendar tool) using webdav to OpenACS's calendar....

Cheers