I pretty much headed off on my own to port documentation for 4.0 to GitHub pages:
http://jasig.github.io/cas/ There's a substantial amount of new high-level content and technical discussion of new features. I would estimate it's about 30-40% done since there's a lot of existing content that needs to be ported. Since I took the effort on by myself I don't assume that it represents the wishes of the whole dev team. While I hope you'll at least take the content and organization if not the whole thing, now seems like a good time to discuss the documentation strategy. My quick list of requirements: - Documentation based on wiki markup - Documentation maintained with source - Reasonable build tools that can support generation in multiple outputs (HTML and PDF at a minimum) - Easy publishing GitHub pages meet all the requirements above. (I have not attempted PDF output, but I believe it's possible.) I think the most important aspect of documentation aside from technology is the handling of contributions. Transition to GitHub pages or anything else that requires repository access is fundamentally curated documentation. While we can take documentation pull requests from contributors, they'll would go through the review/vote/accept process we have used for code. I see that as a benefit, but it's a substantial departure from the "anyone can edit" wiki approach we have at present. There is the Jasig/Apereo ICLA to consider in the analysis of contributions. You could argue that there's an implicit agreement to licensing terms when editing the CASUM wiki, but I would think that the pull request process is much stronger in terms of an implicit agreement. In either case we may need to move to make ICLA compliance explicit, which would happen naturally with curated documentation. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
