|
Hi Doug,
I do not like the idea of a "just talking"
VLT.
I think that from whatever people go to on the
"tutorial day", they should have
something
to take home with them. In other words,
even if it's a short (2 hour) tutorial, people should
be able to pick up an example project as well as setup
instructions, that allows them to
experiment with the stuff on their own (in their freetime
at EclipseCon, or later at home).
IMHO it's not so important to do the actual
hands-on exercises right in class, but to get
help getting started with setup and an initial
project.
I agree that this hasn't been very effective last year,
mostly because speakers typically
distributed their examples in last minute. Having an USB
stick handed out in class
worked OK, but it typically took half an hour or so until
everybody had the examples
on their laptops, and even longer until things were really
set up. So I think the key part
in making tutorials more productive, will be to ask
speakers prepare their material
well in advance and encourage participants
to download examples BEFORE they
enter the tutorial.
When this is done, I think that
* A 2-hour tutorial (aka VLT) would be sufficient to
get participants set up with their
example projects, and walk through the
examples together. In other words, people
would not write code on their own, but
watch the presenters write or explain the
examples. They would typically not have
time to do their own local experiments.
In practice, last year several 4-hour
tutorials were set up like this [but too long
for such a sort of "interactive
presentation".
A 2-hour tutorial should have one
15-minute break in the middle, in which people
can either get some
refreshment or ask presenters for help setting up their
workspaces. The ultimate goal of
a 2-hour tutorial would be that people get
some feeling for the technology,
and (if they want) get a workspace set up
themselves.
* A 4-hour tutorial should follow the same basic
outline as a 2-hour tutorial but have
3 15-minute breaks for setup help,
asking questions or getting refreshment. It would
allow to cover more technical aspects and details,
optionally allow participants to
do a little bit of coding their own
(this worked truly well in the EMF workshop last
year).
The goal of a 4-hour tutorial
would be that people get a workspace set up,
and understand the core APIs of some
technology.
* In a full day workshop, I think the goal should be
that participants not only get
set up, but get some help specific to
their particular needs. In other words, they
should be able to do some coding
their own; they should be able to ask questions
regarding their needs in their current
project. They should be able to experiment
with examples and try their own
side-tracks (assisted by the presenters). I guess
that whoever goes to a Hands-on Workshop
should acutally use what they have
learned in their daily work later
on.
Note that according to this description,
a Hands-on Workshop would actually make
sense for plain beginners or users too
(not only add-in providers), explaining JDT or
PDE features from a user's
perspective ... perhaps a hands-on workshop / beginners
class for
plugin writers would really be well
received.
The goal of a HOW would
be that people get everything they need to use the
technology themselves in
their own projects.
The main background of these thoughts is that the core
value of a tutorial is to get
started with something. After this initial hurdle is taken,
it's always much easier to
explore the help system etc.
The difference between a tutorial and a long talk would
still be that the tutorial digs
into the technology and allows people to actually use it,
while the talk would be
more of a presentation. Therefore, I'd still call the
2-hour thing tutorial rather than
VLT.
HTH,
Here’s
the email thread that I talked about on today’s PMC
call.
In
summary, tutorials become:
Very
Long Talks (2 Hours; 3 per day)
Hands
On Workshops (all day; 1 per day)
So
DSDP can have 3 VLT’s or 1 HOW.
From
our discussion today, I think we agreed that VLT’s would suit the projects
better.
From:
eclipse.org-pmc-leads-bounces@xxxxxxxxxxx
[mailto:eclipse.org-pmc-leads-bounces@xxxxxxxxxxx] On Behalf Of Gaff,
Doug
Sent: Thursday, July 27, 2006 4:12 PM
To: Richard
Gronback; Bjorn Freeman-Benson
Cc: John Graham; Scott Rosenbaum;
eclipse.org-pmc-leads@xxxxxxxxxxx
Subject: [eclipse.org-pmc-leads]
RE: Suggestion for tutorials
The
conversion is as follows: 2 tutorials = 3 VLT’s or 1
HOW
I
think each track lead should survey the projects that fall into their track to
figure out what would suit them better.
From: Richard Gronback
[mailto:richard.gronback@xxxxxxxxxxx]
Sent: Thursday, July 27, 2006
1:22 PM
To: Bjorn Freeman-Benson
Cc: Gaff, Doug;
eclipse.org-pmc-leads@xxxxxxxxxxx; Ed Merks; Scott Rosenbaum; Tim Wagner; John
Graham
Subject: Re: Suggestion for
tutorials
I like the
explicit distinction between hands-on and “just talking” with this approach,
which is as important to the presenters as it is the attendees when
selecting.
I also think it fits well with the concept of
multi-project/track mash-ups, as they would require longer talks and/or
day-long tutorials to do well. If we’re going to do this, we’ll need to
adjust our current allocations to make room. Volunteers?
Who else is in
favor of this approach, and which tracks would like to divide their tutorial
allocation along these lines? Attached is an updated
spreadsheet.
Thanks,
Rich
On 7/27/06 11:49 AM,
"Bjorn Freeman-Benson" <bjorn.freeman-benson@xxxxxxxxxxx>
wrote:
There are no
logistics constraints on tutorial length.
The hands-on tutorials have
not been a big success at EclipseCon in the past few years for a few reasons:
(1) some people don't have laptops (I can't imagine why you would go to a
hands-on tutorial without a laptop, but there it is); (2) the exercises tend
to be too hard to do in a short time (basically, it's very hard to design
small informative coding lessons against the huge Eclipse APIs); (3) many of
the attendees are at the wrong knowledge level to do the exercises
effectively. (Note that there have been successful hands-on tutorials so these
are not 100%.)
So I like this idea. In fact, maybe we should change the
tutorials to two kinds: Very Long Talks (2 Hours; 3 per day) and Hands On
Workshops (all day; 1 per day). The HOW could then be smaller and have
sufficient time to really do a programming exercise. The HOW would be sort of
a plug-in clinic about one specific topic.
Richard Gronback wrote:
Re: Suggestion for
tutorials Hi Doug,
I don’t think it’s a bad idea, although I
personally feel tutorials should be hands-on and not just a long(er)
talk. In reality, not all who attend tutorials come prepared to actually
do hands-on activities, which is unfortunate.
>From last
year’s feedback (http://www.eclipsecon.org/2006/SurveyResults/report.html),
<http://www.eclipsecon.org/2006/SurveyResults/report.html%29,>
it’s not quite clear what the general consensus is, so I’d be interested in
hearing feedback from others on this as well. I’m sure there are some
logistical aspects Bjorn can enlighten us
about.
--
Richard C. Gronback
Borland Software Corporation
richard.gronback@xxxxxxxxxxx
+1
860 227 9215
| 