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