Towards the end of this thread started by Randy Ferrer there were questions about the obsoleteness of various packages. This reminded me that we need to examine the packages that we have for the upcoming OpenACS 5.0 release and I have therefore drafted a package inventory document.

You will note that the tables on the page are glaringly empty, and this is where I was hoping to be able to draw on the help of the community. Above all I am interested in knowing which packages people are interested in maintaining. Let me know if you need permission to edit the document (it is an Edit-This-Page). In addition to adding yourself as maintainer or clarifying what a package does, also feel free to make corrections, i.e. some package may be missing, or a package may be listed as service that is an application etc.

You might notice that I am referring to an OpenACS core team in the document eventhough formally no such team exists yet (informally one could argue it has existed all along). On the day after the Copenhagen OpenACS social there was a meeting to discuss OpenACS governance where Don Baccus and Jeff Davis presented three different examples of governance, those of the Apache, W3C, and Tcl/Tk projects. The recommendation was that what we need something similar to the Tcl/Tk core team and their process for managing patches and feature changes using maintainers and supervisors. I think OpenACS governance will probably be discussed in its own thread. I just wanted to mention it here and now as it is quite relevant to my package inventory list and the OpenACS 5 release.

For anybody who wants to be involved in shaping the governance rules for OpenACS I highly recommend reading TIP #0: Tcl Core Team Basic Rules. The document is written by John Ousterhout, it is quite terse and well thought through, and the OpenACS governance document will probably borrow many ideas, and also wordings, from it.

Randy,
for contributed up-and-coming packages that may not be supported in both databases or haven't been properly tested by the core team yet we have the contrib directory. Packages that have been superseeded or are low in quality and lack maintainer will be phased out in the obsolete directory. A sub-quality package that gets a maintainer could be moved into the contrib package as there is a chance it could one day qualify in to the OpenACS packages directory again.

I'd personally prefer something like unsupported.

I'm not currently using Ticket Tracker, but this could be a good example. There are probably people out there using Ticket Tracker, and not wanting to switch. Let's say in the future they start to clean up the code, expand it, etc.. It wouldn't really be an obsolete package. They may even improve it to the point it would be blessed again.

Maybe I'm raising a stink that doesn't need to be raised. It certainly doesn't affect me much. If so, my apologies. I'd just suggest calling it unsupported, or something else.

Ben Koot on Apr 24 2003 17:16:40
Re: OpenACS 5.0 Package Inventory and OpenACS Governance

Jade ,
A good comment. I was wondering about that too. For example the postcard module. The functionality is what end-users like and may need. I have to admit the presentation at moment is minimal, but from a functional point of view we need it. I guess, a simple tweak will be sufficent to add the "Send picture as postcard" to the Photodb module.
- The functionality is saved
- Developers no longer need to maintain a seperate module.
- It's easier to understand for the end user
- It eliminates the need to write documentation for a seperate module.

I am sure similar integration is possible with other functionality, saves developers time, and increases userability. There's quite a bit duplicate features causing confusion to end users because of the seperate module concept IMHO.

Maybe it makes sense to create a "functionality directory" So How can I.... Non techies hope IT can help to solve simple problems. How sytem engineers make it work? ... they couldn't care less. I am using this approach on my site http://snorri.mine.nu/helpforaday/glossary/glossary?item_id=17560 . As of tomorrow I will have my visitors add questions to the "whishlist".

Just a thought
Ben

- eCommerce
- Authorize.net Payment Gateway
- Shipping Service Contract
- Value based Shipping
- IRC Logger

and together with Janine Sisk:

- Payment Service Contract

/Bart

Disagreements occur. No need to start those things again. But withdrawing without fulfilling your stated responsibities and then expecting to return with full privileges again is not.

talli

I see how we could mark packages as unsupported and reserver obsolete for packages that are superseeded. My main concern is that someone who wants to use OpenACS to solve some problem has a clear picture of what packages to use and how.

I think it is best if everybody who is interested in working on and maintaining a package fills in the columns of that package himself. If you need access privilege to edit the page - let me know.

Thanks!

Having said that, I should be a good fit for the secondary maintainer of the workflow package. I did ported the acs-workflow package to PostgreSQL in the past and did make sure that all ramifications to other packages like CMS, Ticket Tracker and Glossary were up to date (which did take a considerable amount of my free time).

Given this opportunity (and partly answering to  Malte's "original author" question): At the time I had finished the work on workflow package Lars (the original author of the acs-workflow package while at arsdigita) became active in the OpenACS community so I kindly stepped back without even asked for such thing.

(Peter, I have not commited the changes, just in case you have some more to add.)