Am 14.02.2012 um 17:01 schrieb Christopher Brooks: > Jira would be much cleaner, no? We just create a new issue type with > all of the fields we need required in it.
You get the same result in wiki with a template and you can add media, screenshots, diagrams and many more things. These things are very interesting for the adopters of Matterhorn while Sakai didn't need that medias that much. And you can mixed up the media while in Jira, the text is in the body of the ticket and the media is attached at the bottom. > > It also forces adopters who want to identify to get a jira login, which > is key to future collaborations. Same when you use the wiki. Nils > > Chris > > On Tue, 14 Feb 2012 16:58:19 > +0100 Nils Hendrik Birnbaum <[email protected]> wrote: > >> 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 >> > > > > -- > 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] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
