According to Gregs mail if his Proposal will be accepted, this pages should also placed there :-) Nils
--- Nils Hendrik Birnbaum IT-Consultant Requirements Engineer Am 12.02.2012 um 19:46 schrieb Nils Hendrik Birnbaum: > 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] _______________________________________________
