Since my creative outlet has been suppressed by the logo-nazis :-p I will now focus my time on the following:

Helping Dave where I can with the upgrade of openacs.org to 5.2.

I am currently working on a workflow howto guide, as I have recently had some success with it. It is quite a nice package, once you understand what is going on. I will post the guide in the wiki when the wiki gets up and running.

as an OACS newbie and MacUser since 1998, I would like to contribute
some video movies - as those on http://www.backpackit.com - sorry for RoR link
I will record them while getting familiar with core and packages
so I suppose it will be interesting show for newbies

Cheers,
Adam

P.S.
Nick! please include in this new wiki your great manual for dotFolio:
http://dotfolio.org/demo_user/files/view/ENGG1803_BlogBook.pdf
this is exactly what every package should have for end-users

I am using this one:
http://www.ambrosiasw.com/utilities/snapzprox/

I feel it can be interesting to get similar records
from different points of view, my movies will be
probably good for total newbies, since I am still
in the beginning, but yours could be from developer
point of view, so it seems we will not duplicate
efforts - I will do it anyway, just for fun

Cheers,
Adam

I'm glad to help with any mindless drudgery, ie stuff for worker bees.

Should 4.a Description and 4.b Maturity Level be moved to 3.x INCLUDE: CVS summary (and get the info from the .info page)?

Using the same data source would help reducing the burden of updating multiple locations.

Should 4.e and 4.f be moved to 1.x (where plans and issues are posted in bugtracker) to encourage reporting everything in one place (for tracking purposes etc)?

Could the 1.x Bugtracker Summary include counts of bug severity and enhancements (feature requests)?

Could there be another INCLUDE: Code Metrics 5.x with:

a. count of tcl procs
b. count of package-key/tcl lines
c. count of package-key/tcl/test tests
d. count of pg/oracle/shared db functions
e. count of package-key/sql lines (pg/oracle/shared)
f. count of package-key/www/*.adp pages (or all adp pages in the package)
g. count of package-key/lib file pairs

see: http://openacs.org/storage/view/proposals/packages-report.html

for rough example.

The code metrics would help developers quickly realize the level of development and completeness of the code. For example, packages with a low count for tests and lib areas would indicate lacking in meeting newer OpenACS standards, whereas a high count of db functions would indicate an extra burden in maintaining 2 sets of code.

Code metrics might also be useful to others who want to contribute to rounding out a package's weaker points, or make estimates about the burden of maintaining a package etc.

5.h count of package-key/www/doc/*.adp pages
5.i count of lines in package-key/www/doc/*

Either way it is Gustaf's call to make.

they are working on this, see above:
http://openacs.org/forums/message-view?message_id=353020

there are some bugs affecting all OACS installs when initially started on 4.6
if I remember correctly, so I suppose, and believe, they are doing their best
to make it happen as soon as possible

Cheers,
Adam

I saw the thread on this, and I thought it had been resolved so I didn't bother to say anything. But I'll chime in to clarify now:

BSD is wholly GPL-compatible, unless it has the advertising clause. One can slurp a BSD package into a GPL package without license concerns. The reverse is not true, however...unless one is willing to accept a license upgrade from BSD to the stricter GPL for the whole project. GPL is viral, BSD is not.

In short, BSD is an extremely liberal license, barely above public domain. So liberal that relicensing BSD code under a different license is wholly permissible (again, with the possible exception of the advertising clause, which can either be forgiven by the copyright holder, or it can be special-cased in the GPL project...this has been done in some places in the Linux kernel).

There are a lot of thorns in the plethora of licenses out in the wild, but BSD is pretty much wholly thorn free. The only question you need to ask is whether there is an advertising clause, and if not, you're free to pull it into anything you like, including proprietary non-Open products. This is exactly the reason many folks prefer BSD. I'm not one of them, but I understand their reasons.

You've done no wrong in importing BSD code into OpenACS, Malte.

Status Update:

The move of the site to 5.2
is done. Dave Rocks!!

The next hard piece is writing
the includes. I’m looking for skilled volunteers to help with this.
I’m attempting to post $100 bounties on http://bountycounty.org/ for each include. It’s a good chance
to try out their system and hopefully give us some good publicity. It
isn’t much for the work but it’s a token of appreciation. If you’d
like to do it as a straight volunteer position please take the $100
and afterwards post another bounty for something else we need.

Here are some details revised
per Torben’s suggestions. Each include will take a package name as
a parameter.

1. INCLUDE: Bug Tracker
   Summary
1. Open Bugs
2. Last bug Entered
3. Last bug fixed
4. Top bug entering
   user
5. Top bug fixing user
2. INCLUDE: Info file
   Summary (all packages are hyperlinked)
1. Description from
   the .info file
2. Maturity level from
   .info file
3. Package Dependencies
4. Packages that depend
   on this package
3. INCLUDE: CVS Summary
1. Code Metrics:
1. count of tcl procs
2. count of package-key/tcl
   lines
3. count of package-key/tcl/test
   tests
4. count of pg/oracle/shared
   db functions
5. count of package-key/sql
   lines (pg/oracle/shared)
6. count of package-key/www/*.adp
   pages (or all adp pages in the package)
7. count of package-key/lib
   file pairs
8. count of package-key/www/doc/*.adp
   pages
9. count of lines in
   package-key/www/doc/*
2. Last File updated,
   last updating user
3. Number of files
   different between the current release tag and HEAD
4. Most CVS updates
   by user
4. Freeform in the
   wiki, put in headers for each of these and people will fill them in
   as they can.
1. Extended Description
2. Extended Maturity
   Level
1. Checklist of how
   the package is doing on each maturity level criterion
3. Sites and how they
   have used it. Each site should be its own page with back links back
   to all the packages. We should be able to do this with “Pages
   that link to this page”
4. People/Companies
   who can answer questions about this package. Shall we let companies
   also have their own pages in the wiki?
5. Known Issues
6. Future Plans
7. Links to useful
   forum threads, blog posts etc.

You are our first volunteer, yes please do!

XOwiki is mounted at: http://openacs.org/xowiki/

Dave wants to upgrade it at some point as more features/fixes are being added.

Please send email to Dave and he can set you up with access to the dev server for openacs.

Thanks!

To include a bug-tracker summary of a package in a xowiki page, type this:

{{adp /www/templates/bug-tracker {package_key lars-blogger}}}

{{adp /www/templates/info-file {package_key lars-blogger}}}

• The component names in the OpenACS Bug Tracker don't quite match the APM package_key in a consistent manner, so I do a switch statement to translate them. I didn't do every package, since I wasn't sure which ones were going to make it to the wiki, but I can add them as needed.
• I now have sympathy for anyone who's had to work with the bug-tracker. Getting the bug tracker to divulge info it wasn't initially built to divulge is difficult.
• These includes don't do any caching. I can add that if performance is a problem.
• Once I figure out what the url pattern for a package will be in xowiki, I can hyperlink the packages to each other in the info-file summary
• Everything is formatted in HTML tables, cuz that was easiest for me.

TO help go to http://openacs.org/xowiki/ and click the edit button next to a page that has the version number in th ename.

Edit the name attribute to be en:package-key and if you like, also add a human readable title such as "Address Book" in the Title attribute. Then click OK.

Gustaf gave us a way to automatically add the bugtracker and info file includes to pakcage pages, so I'll be doing that soon as well.

Thanks!

I've renamed pages for dotlrn-all and dotlrn-extras modules, and a few more. I will continue with remaining pages during the week.

ACS Admin [en]

instead of

en:ACS Admin

Or better yet, display the country's flag for that specific locale instead of [en].

If that wiki entry were to be translated, then it would look like the following:

ACS Admin [en|fr|db]

Would this be a better approach?

It seems as if dave does not have currently the time to catch up with the developments in xowiki, so the installation of xowiki on oacs.org is quite old. dave uses a customized version of the category browser. Newer versions of xowiki come with a much improved category browser (much less sql queries, opens automatically the tree for a specified page, less jumpy on the screen, etc.), and some other includelets such as one for tracking recently changed xowiki entries similar to "recent posts" on the oacs start page, etc.

i would suggest to wait until the newer stuff is in place. It is quite simple to provide alternate category renders, e.g. by registering a mixin (the renderer is less then 20 lines of code). Currently, i am not sure, what the best way to display categories in a multi-lingual setup is, since the categories themselves have different labels, and once we have 10 or more languages, the flags might look silly.

http://openacs.org/xowiki/?rss=10d

The rss-content is per definition plain text. However, there is as well a weblog-style interface for the content. http://openacs.org/xowiki/pages/en/test-weblog

oacs.org needs an update of the mktree.js file, which has by default the problem of making multiple + symbols when loaded multiple times. I have fixed this problem in mktree.js some time ago, just updateing should help...

no, there is no Wiki "DIFF" function which highlights the changes in the RSS feed. i am not sure what you imagine, since the RSS feed is typically providing new entries, and RSS itself contains only plain text (no HTML), so coloring
the entries is not possible. If someone writes a good HTML-diff function, it could be technically possible to provide a link from the the RSS-feed to show some differences...

It allows you to save movies in Flash format and supports microphone voice overlay.