Home
The Toolkit for Online Communities
17120 Community Members, 0 members online, 1988 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Improvement Proposals (TIPs) : TIP #28: (Approved) Create package-specific enhancement lists under

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

Icon of envelope Request notifications

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.

Collapse
Posted by Jade Rubick on
Sounds like a good idea to me. The package owner would then have an ETP instance, right?
ETP admin permission to the specific package page ....
Collapse
Posted by Dirk Gomez on
Yes, one (or more) people would maintain etp packages and get the necessary permissions.
I support this idea, if multiple people get access to maintain each page, depending on their involvement with the package.
Collapse
Posted by Joel Aufrecht on
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.
Collapse
Posted by Dirk Gomez on
Great proposal, Joel. That avoids duplicated and thus information that will get stale over time.

I volunteer for programming the include snippet for bugtracker.

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.

Collapse
Posted by Dirk Gomez on
Yes, display the tickets' headlines in one snippet and then a blog - that has been my appraising understanding of Joel's proposal.
Collapse
Posted by Dirk Gomez on
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.

Collapse
Posted by Dave Bauer on
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.

Collapse
Posted by Jeff Davis on
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.

Collapse
Posted by Carl Robert Blesius on
Amen Jeff, amen.
Collapse
Posted by Lars Pind on
Yeah. Go ahead. Approved. Though no TIP really required.

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

/Lars

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

/B