Showing 661 - 670 of 694 Postings (
summary)
Created by Carl Blesius, last modified by Gustaf Neumann 01 Feb 2007, at 10:43 AM
[DRAFT] .LRN Motions Document
Background
A .LRN motion is a formal statement of a proposal or question to the .LRN Core Team for consideration and action.
Steps in Presenting .LRN Motions
- Items are presented by .LRN members to the .LRN Core Team in the .LRN Motions Forum. The title must have the motion number, "Proposed", and a short description in it. Example: ".LRN Motion #1 (Proposed): .LRN Motion Rules"
- A .LRN Core Team (LCT) member then must second motion. The title must have "Seconded" in it. Example: ".LRN Motion #1 (Seconded): .LRN Motion Rules"
- Debate. Anyone may post a thread followup. Thread followups must directly address the original .LRN Motion.
- Any LCT member may vote Approval or Disapproval of a Motion. These replies can be titled "Seconded", "Thirded", or "Vetoed".
- Once we have a final status for a TIP, the original title is edited to reflect that.
".LRN Motion #1 (Approved): .LRN Motion Rules"
- All LCT members must subscribe to the forum.
- If a new Motion gets Seconded and Thirded and not Vetoed in the first week after posting, it is Approved. If it gets at least one Veto, the proposer must summarize objections and call for a full vote in a reply titled "Call for Full Vote". Previous Second/Third/Veto votes are then null, and the LCT members vote with replies titled "Approve" or "Disapprove". If, after two weeks of full voting, the Motion has two thirds approval, it is Approved. If not, it is Disapproved.
- After a Motion is Approved or Disapproved, the thread is closed to new posts.
- If a Motion is approved, a ticket is entered into the bugtracker under the proposer's name.
Created by Carl Robert Blesius, last modified by Torben Brosten 12 Jan 2007, at 01:51 PM
This page has been deprecated. See en:Documentation_Project
After years of trying to keep the Docbook based OpenACS documentation up-to-date there has been a movement towards putting the information into a more easily editable format (so you can easily add to this documentation).
This document is part of that migration effort and as such is a work in progress (use the edit button to help).
This WikiDoc Replaces:
Created by Emmanuelle Raffenne, last modified by Emmanuelle Raffenne 07 Jan 2007, at 04:19 PM
Package Specification Summary for Package: wp-slim
| Summary: |
A collaborative online presentation package. |
| Description: |
Wimpy Point allows users to create online slide presentations and supports collaborative editing, customizable style sheets, printable output, and commentability. |
| Maturity: |
New Submission or Maturity Unknown |
| This package depends on: |
acs-content-repository acs-kernel general-comments |
| Packages that depend on wp-slim: |
wps-portlet |
| Package parameters: |
None
|
Bug Tracker Summary for Package: wp-slim
Code Metrics Summary for Package: wp-slim
| # Tcl Procs |
6 |
| # Tcl Lines |
131 |
| # Tcl Blank Lines |
20 |
| # Tcl Comment Lines |
1 |
| # Automated Tests |
0 |
| # Stored Procedures |
PG: 26 ORA: 50 |
| # SQL Lines |
PG: 3058 (blank 360 comments 135)
ORA: 1791 (blank 269 comments 74) |
| # ADP pages |
32 |
| # ADP lines |
1473 |
| # Include pages (wp-slim/lib/) |
0 |
| # Documentation pages |
0
|
| # Documentation lines |
0 |
| Browse Source |
API-browser |
| Github Repository: |
https://github.com/openacs/wp-slim/tree/oacs-5-10
|
Created by Robert Taylor, last modified by Robert Taylor 02 Jan 2007, at 06:32 PM
This is a great cheat sheet for css:
CSS cheet sheet
Created by Robert Taylor, last modified by Torben Brosten 31 Dec 2006, at 08:36 AM
Here are my initial thoughts about standardizing testing of OACS packages:
Testing Servers - all testing is to be done on OACS testing servers found here: http://strauss.gast.it.uc3m.es/
Testing Platform - we are going to start testing the Postgres packages to start with. Testing for Oracle will be added depending on the outcome of the discussion on Oracle support.
Testing Process:
- installation testing - does a package install cleanly
- automated testing - a request has been made to perform automated testing on all packages and create a short list of pass/fail values
- uninstall - does a package uninstall cleanly
- feature testing - test all features in a package and record breakage. We should look at using SELENIUM extrension for Firefox, it allows for recording of things you click on a page.
Packages Being Skipped - it has been mentioned that we should skip the testing of the .LRN packages, at least at first. Any comments on this?
Package Pages - right now we want to keep it simple, one page per package. It is all we need to get started. Each page will have the following items:
- Autogenerated - Package info at the top of the page
- Autogenerated - Bug list pulled in from bug tracker. Code for this is already created, will be submitted to CVS soon.
- Manual Editing - A simple table showing pass/fail for automated testing (step 2. of TESTING PROCESS)
- Manual Editing - Details about steps 1, 3, and 4 of the TESTING PROCESS.
Volunteers:
- Robert Taylor (my self)
- Iuri Sampaio (thanks for the quick vote in previous thread!)
- Hamilton Chua - selenium programming and testing (thanks, this is very cool!)
- ... ??? ... sign up, you know you want to!
Any thoughts are welcome on these points, the general concensus seems to be, don't spend too much time over engineering the process but get some testing done.
More testing references:
Testing with Selenium
en:testing-with-tclwebtest
Created by Avni Khatri, last modified by Avni Khatri 05 Dec 2006, at 10:21 AM
A comparison of features in the CTRL Surveys package and the OACS Assessment package.
The list is intended to go from simple features to more complex features.
| Feature | Surveys | Assessment | Comments |
|---|
File Upload
| no - want to add soon
| yes
|
|
| Branching | yes
| yes
|
|
Publishing
| yes
| yes
|
|
Item Cloning
| yes
|
|
|
Survey/ Section/ Question copying
|
| yes (a.k.a. copy) | Assessment also allows import and export using the IMS QTI standard |
Grouping of Questions
| yes
| yes (a.k.a. sections)
|
|
| Tasks | Surveys uses tasks to allow users to take an instance of a survey. Policies (e.g. interval active, # of times allowed to take) are tied to a task as opposed to a survey.
| Not sure what "tasks" mean in this context. Assessment has sessions (a.k.a. attempts)... is that what this is?
|
|
Policies
| There are quite a few policies designed. Not sure how many are implemented.
| What are policies?
|
|
Reports
| Basic reports
| cvs export and very basic reporting of multiple choice questions
|
|
XML Output
| yes
| yes (IMS QTI)
|
|
Page Flow :)
|
|
|
|
Nomenclature
| uses pages as opposed to sections
don't like item, events
| uses triggers as opposed to events does assess. use questions instead of items?
|
|
|
|
|
|
Created by Avni Khatri, last modified by Emmanuelle Raffenne 07 Nov 2006, at 04:20 PM
If you presented at the 2006 Fall Conference in Boston, please list your presentation below.
You can upload your slides to: https://openacs.org/storage/?folder%5fid=496896
Presentations
- The DGSOM Personnel System, Weekly Message Digest, Room Reservation
System, and Calendar Application
- Towards Full Accessibility in LMS
Created by Marcin Kuczkowski, last modified by Marcin Kuczkowski 28 Oct 2006, at 12:02 PM
Survey module
The session covered the user point of view of the survey module. It also has got some explanation of its data model and inner TCL mechanisms.
TODO: link the recorded webinar here
Created by OpenACS community, last modified by Torben Brosten 25 Oct 2006, at 10:37 AM
PostgreSQL
PostgreSQL is an open-source, ACID-compliant RDBMS
What others say about PostgreSQL
OpenACS uses Postgresql with PL/PgSQL.
Using PostgreSQL with OpenACS
Install PostgreSQL en:postgresql-install
Administrating PostgreSQL en:postgresql-admin
Created by Marcin Kuczkowski, last modified by Marcin Kuczkowski 21 Oct 2006, at 01:36 AM
Site Map Administration
( notes from part 2 of webinar series by Tracy Adams )
- Packages - Applications vs Services
- Package .info Files - xml about the package
- Package Manager - parameters, xml file creation, package installation and upgrade
- Site Map - subsites, permissions, groups, users, registration
- Request Processor - package_id, permissions for an instance
- Site Map API - mount, instantiate_and_mount
Packages - Applications vs Services
Most of the OpenACS code is divided into packages. There are application packages and service packages. Applications are packages like "Room Reservation" or "Photo Album" - something that people, who come to the site can see and use. Services are the parts of the OACS that are not used by users directly, but rather provide functions or data for applications to use.
There is a package repository OpenACS community site divided into channels for each major version of OpenACS.
To use a package on the site, first - install it, then mount it into the Site Map. Consider the example of forums. Assume we have 3 groups of users that will post on different topics. We install forums package, then we mount fhe package in following urls:
/group-1/forum
/group-2/forum
/group-3/forum
Every forum will have its own "package_id", its own users and its own set of permissions. There will be separate data for each forum but the same TCL and ADP files.
Administration pages are at the url: http://yourserver/acs-admin/. Links presented there let admin perform miscellaneous tasks.
To install packages from local filesystem or from OpenACS repository follow "Install software" link.
To mount packages follow the link "Site Map".
