I'm happy to review and comment on the templates too when you have a
draft available Nils,

Chris

On Fri, 17 Feb 2012 12:15:42 -0800 Kevin Chan
<[email protected]> wrote:

> Hi Nils,
> 
> FYI, I stumbled across:
> http://opencast.jira.com/wiki/display/MH/Deployment+Scenarios
> 
> which has some deployment info, so perhaps you can model your
> templates using some of the info there. Also, once you have the
> templates up, I would be happy to stick in some pilot info from UC
> Berkeley to get it going.
> 
>    Kevin Chan
> 
>    Operations Team
>    Educational Technology Services
>    UC Berkeley
> 
> 
> On 2/15/12 8:34 AM, Nils Hendrik Birnbaum wrote:
> > Jep no problem I can generate the template, don't know if we need a 
> > proposal for the general task. Will start ASAP but I have at the 
> > moment some other battlefields that comes first.
> >
> > nils
> >
> > ---
> > Nils Hendrik Birnbaum
> > IT-Consultant
> > Requirements Engineer
> >
> >
> > Am 14.02.2012 um 23:35 schrieb Christopher Brooks:
> >
> >> Don't really see how Sakai requirements are much different than
> >> ours but, if we can do it in the wiki then that's fine.  Are you
> >> able to generate the initial templates up?
> >>
> >> Chris
> >>
> >>
> >> On Tue, 14 Feb 2012 17:09:36 +0100 Nils
> >> Hendrik Birnbaum <[email protected] 
> >> <mailto:[email protected]>> wrote:
> >>
> >>>
> >>> Am 14.02.2012 um 17:01 schrieb Christopher Brooks:
> >>>
> >>>> Jira would be much cleaner, no?  We just create a new issue type
> >>>> with all of the fields we need required in it.
> >>>
> >>> You get the same result in wiki with a template and you can add
> >>> media, screenshots, diagrams and many more things. These things
> >>> are very interesting for the adopters of Matterhorn while Sakai
> >>> didn't need that medias that much.  And you can mixed up the
> >>> media while in Jira, the text is in the body of the ticket and
> >>> the media is attached at the bottom.
> >>>
> >>>>
> >>>> It also forces adopters who want to identify to get a jira login,
> >>>> which is key to future collaborations.
> >>>
> >>> Same when you use the wiki.
> >>>
> >>> Nils
> >>>
> >>>
> >>>>
> >>>> Chris
> >>>>
> >>>> On Tue, 14 Feb 2012 16:58:19
> >>>> +0100 Nils Hendrik Birnbaum <[email protected] 
> >>>> <mailto:[email protected]>> wrote:
> >>>>
> >>>>> A -1 from me for the idea to put in jira. At Matterhorn Project,
> >>>>> the jura is a dangerous place.  The wiki is the right place and
> >>>>> when we provide a good template, we can keep it consistent and
> >>>>> clean. Regards
> >>>>>
> >>>>> Nils
> >>>>>
> >>>>> ---
> >>>>> Nils Hendrik Birnbaum
> >>>>> IT-Consultant
> >>>>> Requirements Engineer
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Am 13.02.2012 um 23:36 schrieb Christopher Brooks:
> >>>>>
> >>>>>> Owen from UCB sent me this link which is how they monitor
> >>>>>> adopters things in Sakai, I actually don't mind it at all.
> >>>>>> Can we do this instead of in the wiki/drupal?:
> >>>>>>
> >>>>>> https://jira.sakaiproject.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10280
> >>>>>>  
> >>>>>> <https://jira.sakaiproject.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10280>
> >>>>>>
> >>>>>> Chris
> >>>>>>
> >>>>>> On Sun, 12 Feb 2012 19:46:15 +0100
> >>>>>> Nils Hendrik Birnbaum <[email protected] 
> >>>>>> <mailto:[email protected]>> wrote:
> >>>>>>
> >>>>>>> Hi Michelle, Kevin, List
> >>>>>>> thanks for sharing your ideas. I took a look at them and
> >>>>>>> merged them with some restriction I know about.
> >>>>>>>
> >>>>>>> So we have two important questions. where should we link it
> >>>>>>> and where should it live.
> >>>>>>>
> >>>>>>> I took a look at the adopters page and recognize, that it's a
> >>>>>>> subpage of "Get involved". There I found Communication:
> >>>>>>> http://opencast.org/communications.
> >>>>>>>
> >>>>>>> I would prefer to add wiki section on that page with some
> >>>>>>> links to several important parts of our wiki. We have a lot of
> >>>>>>> instructing stud deep inside our wiki that could be useful on
> >>>>>>> that page. We can also link from adopters. But in general we
> >>>>>>> can link it from everywhere.
> >>>>>>>
> >>>>>>> The pages should live in the wiki. That would make it a bit
> >>>>>>> difficult. When we put it in the release docs, we have to add
> >>>>>>> them to trunk and all releases. And we have to maintain all
> >>>>>>> identical pages. Otherwise, after n releases we would have n-1
> >>>>>>> outdates pages. So in my opinion we should create an own
> >>>>>>> section in the MHDOC-Wiki. Placing this section in the
> >>>>>>> MH-Wiki would cause issues with the navigation in jira.
> >>>>>>>
> >>>>>>> In first step it could be useful to collect the various
> >>>>>>> configuration with a form that we send on the list. Than I
> >>>>>>> could add them to the wiki to get a basic  setting. Later on
> >>>>>>> the adopters could maintain them directly in the wiki or send
> >>>>>>> them by mail. Next step is, to create a wiki page to collect
> >>>>>>> the attributes on an installation that are interesting for an
> >>>>>>> adopter. Regards
> >>>>>>>
> >>>>>>> Nils
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Am 11.02.2012 um 00:53 schrieb Kevin Chan:
> >>>>>>>
> >>>>>>>> Hi Michelle,
> >>>>>>>>
> >>>>>>>> I think the types of info for the capture agent needed would
> >>>>>>>> basically be a condensed version of what is on the Reference
> >>>>>>>> Hardware page:
> >>>>>>>> http://opencast.jira.com/wiki/display/MHDOC/Reference+Hardware+V1.2
> >>>>>>>>
> >>>>>>>> so it is probably too much info to simply tack on to the MH
> >>>>>>>> adopters pages. However, it would be useful to create a link
> >>>>>>>> from the adopters page to the capture agent pages used by
> >>>>>>>> each institution (though I am not sure how easy that might
> >>>>>>>> be!).
> >>>>>>>>
> >>>>>>>> As for the content of the capture agent page, I see:
> >>>>>>>>
> >>>>>>>> 1. What type/usage of agent (i.e., screencast only, SD video
> >>>>>>>> + screencast, HD video + screencast)? Total number of this
> >>>>>>>> agent in use. 2. Hardware spec (basically something along
> >>>>>>>> the lines of the table for the Reference Hardware page) 3.
> >>>>>>>> MH (or other) Config special to this setup 4. Notes (i.e.,
> >>>>>>>> we have tested running this agent at xxx bitrate and this
> >>>>>>>> uses xxx CPU power)
> >>>>>>>>
> >>>>>>>> 5. [probably not all feasible to include at the start]
> >>>>>>>> Links/info on the institution and maybe other capture
> >>>>>>>> agent/server setup info
> >>>>>>>>
> >>>>>>>> I think the above info would be a good start for a capture
> >>>>>>>> agent info template.
> >>>>>>>>
> >>>>>>>> Kevin Chan
> >>>>>>>>
> >>>>>>>> Operations Team
> >>>>>>>> Educational Technology Services
> >>>>>>>> UC Berkeley
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 2/10/12 6:30 AM, Michelle Ziegmann wrote:
> >>>>>>>>> So we have this page:
> >>>>>>>>> http://opencast.org/matterhorn-adopters, where adopters
> >>>>>>>>> identify themselves as such to the community and provide
> >>>>>>>>> some details about their implementation. It serves a good
> >>>>>>>>> marketing purpose, but the Matterhorn Deployment details
> >>>>>>>>> could be expanded to meet the need you're discussing here
> >>>>>>>>> as well.
> >>>>>>>>>
> >>>>>>>>> I'm preparing to make a call to those adopters on this list
> >>>>>>>>> to update their entries, and to the community for other
> >>>>>>>>> adopters to add themselves. If you all think this format
> >>>>>>>>> could be useful for capturing and providing those
> >>>>>>>>> implementation details, I can first modify this form to
> >>>>>>>>> enable it to collect more information. What do you think?
> >>>>>>>>> If you like the idea, what fields/options would you suggest
> >>>>>>>>> we add?
> >>>>>>>>>
> >>>>>>>>> Or is the information you're seeking too detailed to put
> >>>>>>>>> here?
> >>>>>>>>>
> >>>>>>>>> Michelle
> >>>>>>>>>
> >>>>>>>>> On 2/9/2012 4:18 PM, Kevin Chan wrote:
> >>>>>>>>>> Hi all,
> >>>>>>>>>>
> >>>>>>>>>> I think what Nils is proposing makes sense. Aside from
> >>>>>>>>>> separating/searching by "capture agent types" (screencast
> >>>>>>>>>> only, SD video + screencast, HD video + screencast, etc.),
> >>>>>>>>>> it is also useful to sort by (or provide a list of)
> >>>>>>>>>> institutions' capture agent setup.
> >>>>>>>>>>
> >>>>>>>>>> For example, at UC Berkeley, we are likely going to have 3
> >>>>>>>>>> different types of capture agents - screencast only, SD
> >>>>>>>>>> video
> >>>>>>>>>> + screencast, HD video + screencast - we would also provide
> >>>>>>>>>> additional "institutional" info on why we have these
> >>>>>>>>>> setups, contact info, links to real life MH distributions.
> >>>>>>>>>>
> >>>>>>>>>> Admittedly, this approach works better for system wide
> >>>>>>>>>> applications (we are a large school with this many
> >>>>>>>>>> concurrent/peak users - here is our hardware setup), but I
> >>>>>>>>>> think having this view into how MH is actually being
> >>>>>>>>>> implemented would be useful.
> >>>>>>>>>>
> >>>>>>>>>> Finally, we might even piggy back other MH setup info (like
> >>>>>>>>>> admin/worker/engage setup, storage setup, distribution
> >>>>>>>>>> channels) that would prove useful to other potential
> >>>>>>>>>> adopters.
> >>>>>>>>>>
> >>>>>>>>>> Kevin Chan
> >>>>>>>>>>
> >>>>>>>>>> Operations Team
> >>>>>>>>>> Educational Technology Services
> >>>>>>>>>> UC Berkeley
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 2/8/12 10:22 AM, Nils Hendrik Birnbaum wrote:
> >>>>>>>>>>> Hey Folks,
> >>>>>>>>>>> as I'm working a lot with our documentation I found pages
> >>>>>>>>>>> the were at the first glance outdated. Today when I came
> >>>>>>>>>>> home from office reading some of the mails around the CA
> >>>>>>>>>>> dropped frames - hardware - whatever issues I got the
> >>>>>>>>>>> opinion that outdated is the wrong description - we wrote
> >>>>>>>>>>> them from the wrong point of view and we use terms we all
> >>>>>>>>>>> know well but everybody has his own understanding what he
> >>>>>>>>>>> means. It's one of the major problems in requirements
> >>>>>>>>>>> engineering (RE). To illustrate it, please look at [1]
> >>>>>>>>>>> (german server, english texts). (This cartoon is an
> >>>>>>>>>>> important element in most of the RE certifications)
> >>>>>>>>>>>
> >>>>>>>>>>> I would like to keep the example of the CA. And we should
> >>>>>>>>>>> ask ourselves, what are the information the adopter has
> >>>>>>>>>>> in his mind when he goes to the reference hardware page
> >>>>>>>>>>> and what are the pitfalls we run into day by day.
> >>>>>>>>>>>
> >>>>>>>>>>> In general he would say "I want to record lectures". In
> >>>>>>>>>>> his mind he got more specific ideas how this recording
> >>>>>>>>>>> will join on and what the result of the recording is.
> >>>>>>>>>>> This thought will be affected for example by an existing
> >>>>>>>>>>> system that should be replaced, recordings he saw in the
> >>>>>>>>>>> wild on youtube or iTunes that could be recorded with
> >>>>>>>>>>> Matterhorn or any other system and so on.
> >>>>>>>>>>>
> >>>>>>>>>>> Same with our day by day work. We talk about
> >>>>>>>>>>>
> >>>>>>>>>>> *"successful recordings"  (Framerate, resolution, size,
> >>>>>>>>>>> devices, ...)
> >>>>>>>>>>> * Purchasable hardware (in North America, Europe,
> >>>>>>>>>>> everywhere, ...)
> >>>>>>>>>>>
> >>>>>>>>>>> So the language bites us (free translated by myself). We
> >>>>>>>>>>> should talk more precise, using a glossary ..
> >>>>>>>>>>>
> >>>>>>>>>>> And my approach would be to create the landing page for
> >>>>>>>>>>> our different modules which bases on the adopters
> >>>>>>>>>>> requirements. The first thing that came into my mind is
> >>>>>>>>>>> the quality of the video. That determines the hardware
> >>>>>>>>>>> specs so they can be grouped by 3 or 4 target qualities
> >>>>>>>>>>> and the adopter can watch examples and decide which
> >>>>>>>>>>> hardware he needs.
> >>>>>>>>>>>
> >>>>>>>>>>> This is an easy approach to safe time for answering
> >>>>>>>>>>> questions on the users list caused by different meaning.
> >>>>>>>>>>>
> >>>>>>>>>>> Just my two cents and a small example, please give me some
> >>>>>>>>>>> feedback for kind of an e-mail brainstorming (I will nor
> >>>>>>>>>>> answer this week to stay away from a discussion, we could
> >>>>>>>>>>> to this later on)
> >>>>>>>>>>>
> >>>>>>>>>>> Regards
> >>>>>>>>>>> Nils
> >>>>>>>>>>>
> >>>>>>>>>>> [1]
> >>>>>>>>>>> http://interface-gmbh.de/Anforderungen_WAS_aus_Pj_wurde.JPG
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> Matterhorn mailing list
> >>>>>>>>>>> [email protected] 
> >>>>>>>>>>> <mailto:[email protected]>
> >>>>>>>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> To unsubscribe please email
> >>>>>>>>>>> [email protected] 
> >>>>>>>>>>> <mailto:[email protected]>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> Matterhorn mailing list
> >>>>>>>>>> [email protected] 
> >>>>>>>>>> <mailto:[email protected]>
> >>>>>>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> To unsubscribe please email
> >>>>>>>>>> [email protected] 
> >>>>>>>>>> <mailto:[email protected]>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Matterhorn mailing list
> >>>>>>>> [email protected] 
> >>>>>>>> <mailto:[email protected]>
> >>>>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> To unsubscribe please email
> >>>>>>>> [email protected] 
> >>>>>>>> <mailto:[email protected]>
> >>>>>>>> _______________________________________________
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Matterhorn mailing list
> >>>>>>> [email protected] 
> >>>>>>> <mailto:[email protected]>
> >>>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
> >>>>>>>
> >>>>>>>
> >>>>>>> To unsubscribe please email
> >>>>>>> [email protected] 
> >>>>>>> <mailto:[email protected]>
> >>>>>>> _______________________________________________
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -- 
> >>>>>> Christopher Brooks, BSc, MSc
> >>>>>> ARIES Laboratory, University of Saskatchewan
> >>>>>>
> >>>>>> Web: http://www.cs.usask.ca/~cab938 
> >>>>>> <http://www.cs.usask.ca/%7Ecab938>
> >>>>>> Phone: 1.306.966.1442
> >>>>>> Mail: Advanced Research in Intelligent Educational Systems
> >>>>>> Laboratory Department of Computer Science
> >>>>>>   University of Saskatchewan
> >>>>>>   176 Thorvaldson Building
> >>>>>>   110 Science Place
> >>>>>>   Saskatoon, SK
> >>>>>>   S7N 5C9
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> -- 
> >>>> Christopher Brooks, BSc, MSc
> >>>> ARIES Laboratory, University of Saskatchewan
> >>>>
> >>>> Web: http://www.cs.usask.ca/~cab938
> >>>> <http://www.cs.usask.ca/%7Ecab938> Phone: 1.306.966.1442
> >>>> Mail: Advanced Research in Intelligent Educational Systems
> >>>> Laboratory Department of Computer Science
> >>>>    University of Saskatchewan
> >>>>    176 Thorvaldson Building
> >>>>    110 Science Place
> >>>>    Saskatoon, SK
> >>>>    S7N 5C9
> >>>> _______________________________________________
> >>>> Matterhorn mailing list
> >>>> [email protected]
> >>>> <mailto:[email protected]>
> >>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
> >>>>
> >>>>
> >>>> To unsubscribe please email
> >>>> [email protected] 
> >>>> <mailto:[email protected]>
> >>>> _______________________________________________
> >>>
> >>> _______________________________________________
> >>> Matterhorn mailing list
> >>> [email protected]
> >>> <mailto:[email protected]>
> >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
> >>>
> >>>
> >>> To unsubscribe please email
> >>> [email protected] 
> >>> <mailto:[email protected]>
> >>> _______________________________________________
> >>
> >>
> >>
> >> -- 
> >> Christopher Brooks, BSc, MSc
> >> ARIES Laboratory, University of Saskatchewan
> >>
> >> Web: http://www.cs.usask.ca/~cab938
> >> <http://www.cs.usask.ca/%7Ecab938> Phone: 1.306.966.1442
> >> Mail: Advanced Research in Intelligent Educational Systems
> >> Laboratory Department of Computer Science
> >>     University of Saskatchewan
> >>     176 Thorvaldson Building
> >>     110 Science Place
> >>     Saskatoon, SK
> >>     S7N 5C9
> >
> >
> >
> > _______________________________________________
> > Matterhorn mailing list
> > [email protected]
> > http://lists.opencastproject.org/mailman/listinfo/matterhorn
> >
> >
> > To unsubscribe please email
> > [email protected]
> > _______________________________________________



-- 
Christopher Brooks, BSc, MSc
ARIES Laboratory, University of Saskatchewan

Web: http://www.cs.usask.ca/~cab938
Phone: 1.306.966.1442
Mail: Advanced Research in Intelligent Educational Systems Laboratory
     Department of Computer Science
     University of Saskatchewan
     176 Thorvaldson Building
     110 Science Place
     Saskatoon, SK
     S7N 5C9
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn


To unsubscribe please email
[email protected]
_______________________________________________

Reply via email to