Don't really see how Sakai requirements are much different than ours but, if we can do it in the wiki then that's fine. Are you able to generate the initial templates up?
Chris On Tue, 14 Feb 2012 17:09:36 +0100 Nils Hendrik Birnbaum <[email protected]> wrote: > > 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] > _______________________________________________ -- 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] _______________________________________________
