CASUM Wiki Cleanup

[Marvin Addison]

I promised Jason Shao that I would write up a document on how to make
CAS the authentication provider for Shibboleth.  In reviewing the wiki
to determine the best place to put the document, it has become clear
the wiki needs some spring cleaning.  I reviewed the "Tutorials" and
"Troubleshooting" sections only, and based on those two sections alone
I would recommend the entire wiki be reviewed to address correctness,
organization, and duplication of content.  I'm volunteering to take on
the "Tutorials" and "Troubleshooting" sections and anything related to
LDAP.  Anyone else want to volunteer for some sections?  Is this even
the right way to go about wiki cleanup?  Does the CAS Steering
Committee provide oversight to documentation?  I'm thinking it would
be best for the community to give a first pass at cleanup followed by
committee review and editing.

Thoughts?

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

Go for it, I trust your judgment :-)  I'm tied down with some OpenRegistry stuff before I leave for a school trip/class for a week.  I'll try and help out also when I get back.

On Thu, Jul 9, 2009 at 9:22 AM, Marvin Addison <[hidden email]> wrote:

I promised Jason Shao that I would write up a document on how to make
CAS the authentication provider for Shibboleth.  In reviewing the wiki
to determine the best place to put the document, it has become clear
the wiki needs some spring cleaning.  I reviewed the "Tutorials" and
"Troubleshooting" sections only, and based on those two sections alone
I would recommend the entire wiki be reviewed to address correctness,
organization, and duplication of content.  I'm volunteering to take on
the "Tutorials" and "Troubleshooting" sections and anything related to
LDAP.  Anyone else want to volunteer for some sections?  Is this even
the right way to go about wiki cleanup?  Does the CAS Steering
Committee provide oversight to documentation?  I'm thinking it would
be best for the community to give a first pass at cleanup followed by
committee review and editing.

Thoughts?

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Benn Oshrin-2]

Marvin Addison <[hidden email]> wrote on July 9, 2009 9:22:49
AM -0400:

] I promised Jason Shao that I would write up a document on how to make
] CAS the authentication provider for Shibboleth.

See also eg

 <https://www.switch.ch/aai/docs/shibboleth/SWITCH/1.1/origin/install-cas
.html>
 <https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.1/idp/install-idp-2.
1-cas-debian.html>

-Benn-


--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Marvin Addison]

Thanks for pointing those links out, Benn.  Maybe some folks are still
using Shib 1.1, so the first link might be helpful to them.  As for
the second link, the configuration uses JAAS for LDAP auth and the
important integration steps come much later in the document.
Additionally, they're pretty dated.  Hopefully I'll be able to provide
more succinct and generic instructions for making CAS the
authentication provider for Shib.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Jason Shao (CampusEAI Consortium)]

Thanks Marvin, buy you a drink at the next conference! 2 drinks if we do a
Shib 1.3 & Shib 2.0 version?

Jason

On 7/9/09 3:16 PM, "Marvin Addison" <[hidden email]> wrote:

> Thanks for pointing those links out, Benn.  Maybe some folks are still
> using Shib 1.1, so the first link might be helpful to them.  As for
> the second link, the configuration uses JAAS for LDAP auth and the
> important integration steps come much later in the document.
> Additionally, they're pretty dated.  Hopefully I'll be able to provide
> more succinct and generic instructions for making CAS the
> authentication provider for Shib.
>
> M
>
> --
> You are currently subscribed to [hidden email] as:
> [hidden email]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>

--
Jason Shao
Director of Product Development
CampusEAI Consortium
1940 East 6th Street, 11th Floor
Cleveland, OH 44114
Tel: [phone]x249
Fax: [phone]


Your input is important to improve upon our continuous efforts to service you better. Please e-mail my manager at [hidden email] with any feedback.

CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and confidential; intended for only the recipient(s) named above and may contain information that is privileged. You should not retain, copy or use this e-mail or any attachments for any purpose, or disclose all or any part of the contents to any person. Any views or opinions expressed in this e-mail are those of the author and do not represent those of CampusEAI Consortium or the Open Student Television Network. If you have received this e-mail in error, or are not the named recipient(s), you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited by the sender and to do so might constitute a violation of the Electronic Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender and delete this e-mail and any attachments from your computer. Warning: Although precautions have been taken to make sure no viruses are present in this e-mail, the companies cannot accept responsibility for any loss or damage that arise from the use of this e-mail or attachments.

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Marvin Addison]

I'm done with Wiki cleanup.  I would sincerely appreciate some
community review and feedback.  Summary of changes:

- Added high-level overview text on Home page
- Added "Security Policy" section and added "Ticket Expiration Policy"
page and moved "Remember Me" page there
- Moved a number of pages from the "Troubleshooting" section to the
"Tutorials and HOWTOs" section and tried to clarify titles
- Added content to "SAML 1.1" protocol page
- Added "Shibboleth-CAS Integration" page
- Added some text to a number of section header pages

Some points for consideration:

- I was concerned about disagreement between some claims I made in the
"Availability" section of the home page and the "Clustering" page.
From my experience with JpaTicketRegistry, all you need for high
availability is an active-active load balanced setup and a distributed
registry.  The "Clustering" page has a number of additional concerns.

- Consider consolidating "Deploying CAS 3.0.x in RHEL 5 with Sun Java"
with "HOWTO Switch to Sun JVM in RHEL" or delete for former
altogether.

- Delete the following pages as their content is covered elsewhere:
  - "HOWTO Configure Single Sign On Session Timeout" (covered in
"Ticket Expiration Policy")
  - "How to Fedora 10 + CAS 3.3.1 + OpenLDAP 2.4.12 + DIGEST-MD5"
(covered in last example on "LDAP")

- Search and destroy duplicated content.  I caught some, but it will
take a thorough review to catch it all.  Duplicated content is an
editorial nightmare, and, as such, content convered in multiple places
is frequently in disagreement.  Conflicting documentation is worse
than no documentation at all.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Kim Cary]

Thanks for doing all that. Especially appreciated the Security Policy changes and the additon of content in saml 1.1. No changes on quick review, but I know where to stow them if I find any issues.

On Fri, Jul 10, 2009 at 9:09 AM, Marvin Addison <[hidden email]> wrote:

I'm done with Wiki cleanup.  I would sincerely appreciate some
community review and feedback.  Summary of changes:

- Added high-level overview text on Home page
- Added "Security Policy" section and added "Ticket Expiration Policy"
page and moved "Remember Me" page there
- Moved a number of pages from the "Troubleshooting" section to the
"Tutorials and HOWTOs" section and tried to clarify titles
- Added content to "SAML 1.1" protocol page
- Added "Shibboleth-CAS Integration" page
- Added some text to a number of section header pages

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Andrew Feller]

M,

Does it make sense to restructure the CAS User Manual section of the wiki
based upon version / series of CAS being deployed?  I have been thinking
about this sometime as I was the one who started the "Deploying CAS 3.0.x
..." page a few years ago.

The reason I bring it up is that some information is:

1) Particular for a minor series (3.0.X, 3.1.X, etc)
2) Particular for a major series (3.X, 4.X, etc)

I am not saying I have a fully fleshed out plan for dealing with information
that crosses series, but I like some thoughts on the idea.

Thanks for the good work,
A-

On 7/10/09 11:09 AM, "Marvin Addison" <[hidden email]> wrote:

> I'm done with Wiki cleanup.  I would sincerely appreciate some
> community review and feedback.  Summary of changes:
>
> - Added high-level overview text on Home page
> - Added "Security Policy" section and added "Ticket Expiration Policy"
> page and moved "Remember Me" page there
> - Moved a number of pages from the "Troubleshooting" section to the
> "Tutorials and HOWTOs" section and tried to clarify titles
> - Added content to "SAML 1.1" protocol page
> - Added "Shibboleth-CAS Integration" page
> - Added some text to a number of section header pages
>
> Some points for consideration:
>
> - I was concerned about disagreement between some claims I made in the
> "Availability" section of the home page and the "Clustering" page.
> From my experience with JpaTicketRegistry, all you need for high
> availability is an active-active load balanced setup and a distributed
> registry.  The "Clustering" page has a number of additional concerns.
>
> - Consider consolidating "Deploying CAS 3.0.x in RHEL 5 with Sun Java"
> with "HOWTO Switch to Sun JVM in RHEL" or delete for former
> altogether.
>
> - Delete the following pages as their content is covered elsewhere:
>   - "HOWTO Configure Single Sign On Session Timeout" (covered in
> "Ticket Expiration Policy")
>   - "How to Fedora 10 + CAS 3.3.1 + OpenLDAP 2.4.12 + DIGEST-MD5"
> (covered in last example on "LDAP")
>
> - Search and destroy duplicated content.  I caught some, but it will
> take a thorough review to catch it all.  Duplicated content is an
> editorial nightmare, and, as such, content convered in multiple places
> is frequently in disagreement.  Conflicting documentation is worse
> than no documentation at all.
>
> M

--
Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: [phone]



--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

I thought about that, but there's very little information that changes each version.  We're usually just adding new features. We can probably do a better job of keeping a changelog in the manual though, as well as specifying minimum versions on the manual pages.

I know some places like Atlassian keep separate manuals per version, but then they also pay documentation writers... ;-)  I'm also not sure how well our instance of Confluence would hold up with lots of new pages.  I also don't want to be the one correcting errors on multiple pages ;-)

On Fri, Jul 10, 2009 at 1:29 PM, Andrew Feller <[hidden email]> wrote:

M,

Does it make sense to restructure the CAS User Manual section of the wiki
based upon version / series of CAS being deployed?  I have been thinking
about this sometime as I was the one who started the "Deploying CAS 3.0.x
..." page a few years ago.

The reason I bring it up is that some information is:

1) Particular for a minor series (3.0.X, 3.1.X, etc)
2) Particular for a major series (3.X, 4.X, etc)

I am not saying I have a fully fleshed out plan for dealing with information
that crosses series, but I like some thoughts on the idea.

Thanks for the good work,
A-

On 7/10/09 11:09 AM, "Marvin Addison" <[hidden email]> wrote:

> I'm done with Wiki cleanup.  I would sincerely appreciate some
> community review and feedback.  Summary of changes:
>
> - Added high-level overview text on Home page
> - Added "Security Policy" section and added "Ticket Expiration Policy"
> page and moved "Remember Me" page there
> - Moved a number of pages from the "Troubleshooting" section to the
> "Tutorials and HOWTOs" section and tried to clarify titles
> - Added content to "SAML 1.1" protocol page
> - Added "Shibboleth-CAS Integration" page
> - Added some text to a number of section header pages
>
> Some points for consideration:
>
> - I was concerned about disagreement between some claims I made in the
> "Availability" section of the home page and the "Clustering" page.
> From my experience with JpaTicketRegistry, all you need for high
> availability is an active-active load balanced setup and a distributed
> registry.  The "Clustering" page has a number of additional concerns.
>
> - Consider consolidating "Deploying CAS 3.0.x in RHEL 5 with Sun Java"
> with "HOWTO Switch to Sun JVM in RHEL" or delete for former
> altogether.
>
> - Delete the following pages as their content is covered elsewhere:
>   - "HOWTO Configure Single Sign On Session Timeout" (covered in
> "Ticket Expiration Policy")
>   - "How to Fedora 10 + CAS 3.3.1 + OpenLDAP 2.4.12 + DIGEST-MD5"
> (covered in last example on "LDAP")
>
> - Search and destroy duplicated content.  I caught some, but it will
> take a thorough review to catch it all.  Duplicated content is an
> editorial nightmare, and, as such, content convered in multiple places
> is frequently in disagreement.  Conflicting documentation is worse
> than no documentation at all.
>
> M

--

Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: [phone]

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Andrew Feller]

Some javascript/style in this post has been disabled (why?)

It would be interesting if Confluence or a wiki allowed for pages to be dynamically organized based on tags so you could ask for all material for CAS X.X or X.X.X and it would be smart enough to accumulate it together.  * dreaming *

Now that wishful dreaming is out of the way, I think we can admit that having documentation per version is definitely helpful from a user’s perspective; simply isn’t efficient from a maintainer perspective.

On 7/10/09 12:33 PM, "Scott Battaglia" <scott.battaglia@...> wrote:

I thought about that, but there's very little information that changes each version.  We're usually just adding new features. We can probably do a better job of keeping a changelog in the manual though, as well as specifying minimum versions on the manual pages.

I know some places like Atlassian keep separate manuals per version, but then they also pay documentation writers... ;-)  I'm also not sure how well our instance of Confluence would hold up with lots of new pages.  I also don't want to be the one correcting errors on multiple pages ;-)



On Fri, Jul 10, 2009 at 1:29 PM, Andrew Feller <afelle1@...> wrote:

M,

Does it make sense to restructure the CAS User Manual section of the wiki
based upon version / series of CAS being deployed?  I have been thinking
about this sometime as I was the one who started the "Deploying CAS 3.0.x
..." page a few years ago.

The reason I bring it up is that some information is:

1) Particular for a minor series (3.0.X, 3.1.X, etc)
2) Particular for a major series (3.X, 4.X, etc)

I am not saying I have a fully fleshed out plan for dealing with information
that crosses series, but I like some thoughts on the idea.

Thanks for the good work,
A-

On 7/10/09 11:09 AM, "Marvin Addison" <marvin.addison@...> wrote:

> I'm done with Wiki cleanup.  I would sincerely appreciate some
> community review and feedback.  Summary of changes:
>
> - Added high-level overview text on Home page
> - Added "Security Policy" section and added "Ticket Expiration Policy"
> page and moved "Remember Me" page there
> - Moved a number of pages from the "Troubleshooting" section to the
> "Tutorials and HOWTOs" section and tried to clarify titles
> - Added content to "SAML 1.1" protocol page
> - Added "Shibboleth-CAS Integration" page
> - Added some text to a number of section header pages
>
> Some points for consideration:
>
> - I was concerned about disagreement between some claims I made in the
> "Availability" section of the home page and the "Clustering" page.
> From my experience with JpaTicketRegistry, all you need for high
> availability is an active-active load balanced setup and a distributed
> registry.  The "Clustering" page has a number of additional concerns.
>
> - Consider consolidating "Deploying CAS 3.0.x in RHEL 5 with Sun Java"
> with "HOWTO Switch to Sun JVM in RHEL" or delete for former
> altogether.
>
> - Delete the following pages as their content is covered elsewhere:
>   - "HOWTO Configure Single Sign On Session Timeout" (covered in
> "Ticket Expiration Policy")
>   - "How to Fedora 10 + CAS 3.3.1 + OpenLDAP 2.4.12 + DIGEST-MD5"
> (covered in last example on "LDAP")
>
> - Search and destroy duplicated content.  I caught some, but it will
> take a thorough review to catch it all.  Duplicated content is an
> editorial nightmare, and, as such, content convered in multiple places
> is frequently in disagreement.  Conflicting documentation is worse
> than no documentation at all.
>
> M

--
Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: [phone]



--
You are currently subscribed to cas-user@... as: scott.battaglia@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

--
Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: [phone]

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

If you know any good documentation writers willing to accept user abuse and no pay, be sure to send them my way :-)

On Fri, Jul 10, 2009 at 1:42 PM, Andrew Feller <[hidden email]> wrote:

It would be interesting if Confluence or a wiki allowed for pages to be dynamically organized based on tags so you could ask for all material for CAS X.X or X.X.X and it would be smart enough to accumulate it together.  * dreaming *

Now that wishful dreaming is out of the way, I think we can admit that having documentation per version is definitely helpful from a user’s perspective; simply isn’t efficient from a maintainer perspective.

On 7/10/09 12:33 PM, "Scott Battaglia" <scott.battaglia@...> wrote:

I thought about that, but there's very little information that changes each version.  We're usually just adding new features. We can probably do a better job of keeping a changelog in the manual though, as well as specifying minimum versions on the manual pages.

I know some places like Atlassian keep separate manuals per version, but then they also pay documentation writers... ;-)  I'm also not sure how well our instance of Confluence would hold up with lots of new pages.  I also don't want to be the one correcting errors on multiple pages ;-)



On Fri, Jul 10, 2009 at 1:29 PM, Andrew Feller <afelle1@...> wrote:

M,

Does it make sense to restructure the CAS User Manual section of the wiki
based upon version / series of CAS being deployed?  I have been thinking
about this sometime as I was the one who started the "Deploying CAS 3.0.x
..." page a few years ago.

The reason I bring it up is that some information is:

1) Particular for a minor series (3.0.X, 3.1.X, etc)
2) Particular for a major series (3.X, 4.X, etc)

I am not saying I have a fully fleshed out plan for dealing with information
that crosses series, but I like some thoughts on the idea.

Thanks for the good work,
A-

On 7/10/09 11:09 AM, "Marvin Addison" <marvin.addison@...> wrote:

> I'm done with Wiki cleanup.  I would sincerely appreciate some
> community review and feedback.  Summary of changes:
>
> - Added high-level overview text on Home page
> - Added "Security Policy" section and added "Ticket Expiration Policy"
> page and moved "Remember Me" page there
> - Moved a number of pages from the "Troubleshooting" section to the
> "Tutorials and HOWTOs" section and tried to clarify titles
> - Added content to "SAML 1.1" protocol page
> - Added "Shibboleth-CAS Integration" page
> - Added some text to a number of section header pages
>
> Some points for consideration:
>
> - I was concerned about disagreement between some claims I made in the
> "Availability" section of the home page and the "Clustering" page.
> From my experience with JpaTicketRegistry, all you need for high
> availability is an active-active load balanced setup and a distributed
> registry.  The "Clustering" page has a number of additional concerns.
>
> - Consider consolidating "Deploying CAS 3.0.x in RHEL 5 with Sun Java"
> with "HOWTO Switch to Sun JVM in RHEL" or delete for former
> altogether.
>
> - Delete the following pages as their content is covered elsewhere:
>   - "HOWTO Configure Single Sign On Session Timeout" (covered in
> "Ticket Expiration Policy")
>   - "How to Fedora 10 + CAS 3.3.1 + OpenLDAP 2.4.12 + DIGEST-MD5"
> (covered in last example on "LDAP")
>
> - Search and destroy duplicated content.  I caught some, but it will
> take a thorough review to catch it all.  Duplicated content is an
> editorial nightmare, and, as such, content convered in multiple places
> is frequently in disagreement.  Conflicting documentation is worse
> than no documentation at all.
>
> M

--
Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: [phone]



--
You are currently subscribed to cas-user@... as: scott.battaglia@...
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

--

Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: [phone]

-- 
You are currently subscribed to [hidden email] as: [hidden email]


To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Marvin Addison]

> If you know any good documentation writers willing to accept user abuse and
> no pay, be sure to send them my way :-)

I like the occasional writing and editing task; feel free to call on
me when needed.  More than editors, though, I think the Wiki could
_really_ benefit from annual review by the Steering Committee.  I'm
sure a number of folks could be convinced to write and edit once an
administrative body has reviewed content and determined areas for
improvement.  I would argue the content review process is _much_
harder/time consuming than actually making changes.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

On Fri, Jul 10, 2009 at 2:06 PM, Marvin Addison <[hidden email]> wrote:

> If you know any good documentation writers willing to accept user abuse and
> no pay, be sure to send them my way :-)

I like the occasional writing and editing task; feel free to call on
me when needed.  More than editors, though, I think the Wiki could
_really_ benefit from annual review by the Steering Committee.  I'm
sure a number of folks could be convinced to write and edit once an
administrative body has reviewed content and determined areas for
improvement.  I would argue the content review process is _much_
harder/time consuming than actually making changes.

Not to sound jaded, but I tried that at least once already, if not more times.  Clearly I tried it before you were actively reading the list ;-)


 

M

--

You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

On Fri, Jul 10, 2009 at 2:06 PM, Marvin Addison <[hidden email]> wrote:

> If you know any good documentation writers willing to accept user abuse and
> no pay, be sure to send them my way :-)

I like the occasional writing and editing task; feel free to call on
me when needed.  More than editors, though, I think the Wiki could
_really_ benefit from annual review by the Steering Committee.

I'm not really sure we want the Steering Committee being in charge of this.  I think a number of trusted volunteers and interested parties would be a better way to go, as well as at least the development team reviewing it.  I think we'd only want to bring it to the Steering Committee if there were major quality control, lapses, or issues (which hopefully there are none) or we need them to locate resources.

That said, I'm on the steering committee, so I may be biased ;-)


 

 I'm
sure a number of folks could be convinced to write and edit once an
administrative body has reviewed content and determined areas for
improvement.  I would argue the content review process is _much_
harder/time consuming than actually making changes.

M

--

You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Marvin Addison]

> I'm not really sure we want the Steering Committee being in charge of this.

Clearly I disagree.  Documentation, like design, benefits from a
small, focused team of individuals in charge.  It seems entirely
feasible to me that the Steering Committee could conduct an annual
review of the wiki, post a "todo" list of changes needed, and request
volunteers to actually make the edits.  Whether or not volunteers take
up the content change tasks, the review would produce tangible
documentation for areas of improvement.

> we'd only want to bring it to the Steering Committee if there were
> major quality control, lapses, or issues

The wiki suffers from some organization problems and incomplete and
conflicting content.  It's a matter of opinion whether the details of
those problems constitute a major quality control problem.  Given a
feasible process for correcting those problems, we should doubtless
correct them.  My proposal for annual review by the Steering Committee
is one potential solution.  It puts the decision making process in the
hands of a small number of qualified people, and that is a good thing.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

On Fri, Jul 10, 2009 at 2:08 PM, Scott Battaglia <[hidden email]> wrote:

On Fri, Jul 10, 2009 at 2:06 PM, Marvin Addison <[hidden email]> wrote:

> If you know any good documentation writers willing to accept user abuse and
> no pay, be sure to send them my way :-)

I like the occasional writing and editing task; feel free to call on
me when needed.  More than editors, though, I think the Wiki could
_really_ benefit from annual review by the Steering Committee.  I'm
sure a number of folks could be convinced to write and edit once an
administrative body has reviewed content and determined areas for
improvement.  I would argue the content review process is _much_
harder/time consuming than actually making changes.

Not to sound jaded, but I tried that at least once already, if not more times.  Clearly I tried it before you were actively reading the list ;-)

Just to avoid any confusion, I meant I tried recruiting various folks to write various specific sections after I did reviews and noticed gaps with varying degrees of success.  Not that I tried to recruit Marvin to do all of them (wish I could, but his management might object to that!).

 

 

M

--

You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user