On 8/27/2012 10:48 PM, Nils Birnbaum [via Opencast] wrote:
Hi Greg,
> I am somewhat against making MHDOC editable by anyone. I think
having a
> set of documentation that's difficult to change, and thus somewhat more
> official, is useful in the sense that we can depend on it to not get
> moved around too much.
Greg and Chris, I'd like to propose we reconsider the way the release
documents are structured. Do we really need to create a complete set of
installation and configuration guides for each release? Why not just
have 1 installation and 1 configuration guide that is updated for the
current release? We could include within those documents pointers for
previous releases (or even trunk). Then the actual release notes can be
limited to a list of what's changed. It would make the release process
much easier as well, not having to reproduce and fix links in 25+ pages.
The links would remain constant, which has benefits.
Regarding the concern about opening up access. We could still restrict
editing of these pages to a limited group of people. We could also relay
on "watching" pages to monitor for changes, thereby allowing
contributors an opportunity to improve our documentation. Additionally,
as developers add new features that has impact on installation and
configuration, they would be responsible for updating the installation
and configuration guides. There is pretty robust change log and version
control functionality built in.
I found a function in Jiras confic section that allows to restrict the
edit permission for single pages. That means that we had never open an
extra Wiki and in general everything could be in one Wiki with top
sections for Adopters and Developers and restricted areas.
You could always change the view/edit rights for specific pages, that's
nothing new. We have several pages in the wiki that are limited in that way.
However, the problem with having everything in one wiki is that the
developers tend to (and need to) have flexibility to add documents about
proposals in progress, draft, ideas, and keep historical things around
that are no longer relevant. They can tolerate a kind of messy wiki
because it's their working area. If everything is in one wiki, search
becomes a problem when all of those irrelevant documents come up. How
does an adopter know what is the current and real information? In a
separate wiki, we keep a much smaller set of documents that are current
and relevant, and structure this is a way that makes sense to an
adopter. And when searching is restricted to one space, searching will
be more useful.
Michelle
Nils
>
> I'm not against this enough to vote this down though, but I figured I
> would bring this up for people to discuss. The rest of the proposals
> (especially #2!) seem very useful.
>
> G
>
>> The Documentation Working Group
>> _______________________________________________
>> Community mailing list
>> [hidden email] </user/SendEmail.jtp?type=node&node=7581472&i=0>
>> http://lists.opencastproject.org/mailman/listinfo/community
>>
>>
>> To unsubscribe please email
>> [hidden email] </user/SendEmail.jtp?type=node&node=7581472&i=1>
>> _______________________________________________
>
>
> _______________________________________________
> Community mailing list
> [hidden email] </user/SendEmail.jtp?type=node&node=7581472&i=2>
> http://lists.opencastproject.org/mailman/listinfo/community
>
>
> To unsubscribe please email
> [hidden email] </user/SendEmail.jtp?type=node&node=7581472&i=3>
> _______________________________________________
_______________________________________________
Community mailing list
[hidden email] </user/SendEmail.jtp?type=node&node=7581472&i=4>
http://lists.opencastproject.org/mailman/listinfo/community
To unsubscribe please email
[hidden email] </user/SendEmail.jtp?type=node&node=7581472&i=5>
_______________________________________________
------------------------------------------------------------------------
If you reply to this email, your message will be added to the
discussion below:
http://opencast.3480289.n2.nabble.com/Opencast-New-proposal-for-wiki-gardening-tp7581458p7581472.html
To start a new topic under Opencast Community, email
[email protected]
To unsubscribe from Opencast Community, click here
<http://opencast.3480289.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1101673&code=bWljaGVsbGVAbWVkaWEuYmVya2VsZXkuZWR1fDExMDE2NzN8LTIwOTc4Nzg3NjQ=>.
NAML
<http://opencast.3480289.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
Michelle Ziegmann
Educational Technology Services
University of California Berkeley
_______________________________________________
Community mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/community
To unsubscribe please email
[email protected]
_______________________________________________
