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 > > Chris > > On Sun, 12 Feb 2012 19:46:15 +0100 > Nils Hendrik Birnbaum <[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] >>>>>> 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] >>>>> _______________________________________________ >>>> >>> _______________________________________________ >>> 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] >> _______________________________________________ > > > > -- > 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] _______________________________________________
