Jira would be much cleaner, no? We just create a new issue type with all of the fields we need required in it.
It also forces adopters who want to identify to get a jira login, which is key to future collaborations. 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] _______________________________________________
