Michelle,
Just to be clear, here is what I am suggesting, using 1.3 as an example:

+ Release 1.3   <---- if the user clicks on Release 1.3, without expanding, 
they would see the release notes for 1.3 (See below for proposed outline of 
what could be included per release page)

- Release 1.3    <--- if the user expands the Release 1.3 page(s) they see an 
expanded view which includes sub-pages that are stand-alone. 
-- Release 1.3.1  <--- if the user clicks on Release 1.3.1 they would see the 
release notes for only 1.3.1 
-- Release 1.3.2

I would also suggest that we need an outline for each of the release pages 
(1.3, 1.3.1, etc) that is consistent and provides a bit more detail than just a 
change list, for example each release page could contain:

1. Release Highlights - high level overview 
2. Major Release Changes - describe major features that have been changes, 
altered, etc. 
3. Installation Changes - if there is a "master" page for installations it 
should be referenced here and only changes to that process should be 
highlighted and called out
4. Upgrading from Previous Version - Describe how to upgrade
5. Detailed change List - what is currently listed on 1.3 page is example of 
what could be found here
6. API Changes  - API changes, if any, could be listed

aw



On Sep 7, 2012, at 8:59 AM, Michelle Ziegmann <[email protected]> 
wrote:

> +1 to moving the FAQ outside of the release notes and making this more 
> general across all releases (release-specific responses could be indicated as 
> such).
> 
> Regarding your 2nd question, just to clarify, you are proposing that a 
> "release 1.3.1" addition will be 1 page added at the top level of the Release 
> 1.3 space. That makes sense. I also wonder if the main 1.3 installation pages 
> where a pointer is provided toward checking out a release, that it be updated 
> to point to the latest release. For example, on 
> http://opencast.jira.com/wiki/display/MHDOC/Install+Source+OS+X+v1.3, step 2 
> to checkout Matterhorn source should probably be updated to point to 1.3.1. 
> Right? I don't know how many places like that exist in the release docs - 
> probably not too many I would guess.
> 
> Michelle
> 
> On 9/7/12 8:25 AM, Andy Wasklewicz wrote:
>> Thanks Michelle. 
>> 
>> I have a few questions/suggestions:
>> 
>> Section - Release Docs
>> 1. Is the FAQ necessary in every release notes section? it seems "generic" 
>> and could be moved to a "higher level" and linked to if necessary instead of 
>> duplicating for every release?
>> 2. It may be clearer (although I have seen it done both ways) if there are 
>> individual pages per release, for example:
>> 
>> Release 1.3  (should contain notes about 1.3 release)
>> - Release 1.3.1 (sub page to master  - Release 1.3 - with release notes for 
>> 1.3.1)
>> - Release 1.3.2 (sub page to master  - Release 1.3 - with release notes for 
>> 1.3.2)
>> - Release 1.3.3 (sub page to master  - Release 1.3 - with release notes for 
>> 1.3.3)
>> 
>> Andy
>> 
>> -----------------------
>> 
>> On Sep 6, 2012, at 3:29 PM, Michelle Ziegmann <[email protected]> 
>> wrote:
>> 
>>> Hi all,
>>> 
>>> As part of the adopter documentation improvement initiative, I've gone 
>>> ahead and experimented with the idea we discussed on list to create a 
>>> separate wiki space for each version of the release docs. I copied each 
>>> page of the trunk docs into a new space at 
>>> http://opencast.jira.com/wiki/display/MHTRUNK/Home.
>>> 
>>> After playing around some, I think this will work well for us. Greg will 
>>> find it to be a much easier task to create a new version of the docs with 
>>> each release. There is a new plugin now to "Copy Space", so when releasing 
>>> a new version, you copy the entire MHTRUNK space to something like MH14 - 
>>> all links intact. No need to add " (1.4)" to the end of every page to get 
>>> around the unique page title issue either.
>>> 
>>> Links to the release docs will be provided in 
>>> http://opencast.jira.com/wiki/display/MHDOC/Matterhorn+Documentation.
>>> 
>>> If there is agreement with this proposal, the next steps I will take are:
>>> 
>>> 1. Delete all of these pages - 
>>> http://opencast.jira.com/wiki/display/MH/Trunk. Instead, confluence users 
>>> will have access to edit http://opencast.jira.com/wiki/display/MHTRUNK/Home 
>>> (I just made the copy today, so everything is up to date as of earlier this 
>>> afternoon).
>>> 
>>> 2. Move each version of release docs from 
>>> http://opencast.jira.com/wiki/display/MHDOC/Matterhorn+Documentation to 
>>> individual spaces, then provide the links to those spaces. These spaces 
>>> will only be editable by the documentation maintainers.
>>> 
>>> 3. Open up the permissions for MHDOC so that any current confluence users 
>>> can edit and contribute guides.
>>> 
>>> 4. Continue restructuring 
>>> http://opencast.jira.com/wiki/display/MHDOC/Matterhorn+Documentation to 
>>> more of an "Adopter Guides" focus, with links to the release docs plus 
>>> other useful guides for adopters. Some documents from the developer's wiki 
>>> will be moved here that are relevant for adopters. The general structure 
>>> was proposed in an earlier thread http://goo.gl/1YJ8J.
>>> 
>>> Please let me know if you have any questions, suggestions or concerns about 
>>> this proposal. I'd like to make these moves as soon as possible, to avoid 
>>> any duplication of effort with ongoing changes between the current and new 
>>> TRUNK docs.
>>> 
>>> Thanks!
>>> Michelle
>>> 
>>> -- 
>>> =================
>>> Michelle Ziegmann
>>> Technical Project Manager
>>> Educational Technology Services
>>> University of California Berkeley
>>> 
>>> _______________________________________________
>>> Matterhorn mailing list
>>> [email protected]
>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
>>> 
>>> 
>>> To unsubscribe please email
>>> [email protected]
>>> _______________________________________________
>> 
>> 
>> 
>> _______________________________________________
>> Matterhorn mailing list
>> [email protected]
>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
>> 
>> 
>> To unsubscribe please email
>> [email protected]
>> _______________________________________________
> 
> -- 
> =================
> Michelle Ziegmann
> Technical Project Manager
> Educational Technology Services
> University of California Berkeley
> _______________________________________________
> Matterhorn mailing list
> [email protected]
> http://lists.opencastproject.org/mailman/listinfo/matterhorn
> 
> 
> To unsubscribe please email
> [email protected]
> _______________________________________________

_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn


To unsubscribe please email
[email protected]
_______________________________________________

Reply via email to