Also, what does a "resolved" adopter mean? :-)
On 14.02.2012, at 00:27, Kevin Chan wrote: > Hi Chris, > > One challenge with the "Jira" model for this information is how does an > institution list multiple capture agent devices? And once listed, how is a > potential adopter going to be able to find, for example, "current adopters > with HD camera + screencast setup"? > > Nonetheless, it is always better to have the data somewhere, then not at all. > One improvement (from the Sakai model) is to link the opencast.org "Adopters" > page to this info, wherever it may lie. > > Kevin Chan > > Operations Team > Educational Technology Services > UC Berkeley > > > On 2/13/12 2:36 PM, Christopher Brooks wrote: >> 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] >>> _______________________________________________ >> >> > _______________________________________________ > 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] _______________________________________________
