Hi Chris,
One challenge with the "Jira" model for this information is how does an
institution list multiple capture agent devices? And once listed, how is
a potential adopter going to be able to find, for example, "current
adopters with HD camera + screencast setup"?
Nonetheless, it is always better to have the data somewhere, then not at
all. One improvement (from the Sakai model) is to link the opencast.org
"Adopters" page to this info, wherever it may lie.
Kevin Chan
Operations Team
Educational Technology Services
UC Berkeley
On 2/13/12 2:36 PM, Christopher Brooks wrote:
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]
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
