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] _______________________________________________
