[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Photo policy for DebConf



Hi,

though a month late, I'd still like to comment on this thread.

On Sun, Aug 05, 2018 at 11:26:21PM +0800, Louis-Philippe Véronneau wrote:
> On 2018-08-03 08:40, Paul Wise wrote:
> > Not having video pans of the audience since it doesn't necessarily add
> > much value to the streams and having no-video audience areas (with
> > microphone) would also be appreciated, I've had people ask me to ask
> > questions on their behalf because of current practices.
> Although I'm part of the DebConf video team, I have to say I also do not
> like to be on pictures or videos. Kinda ironic :9
 
Same here. (Though migated by years of being on videos.)

> I wish there was an easy way for us to make this happen, but I don't see
> how the DebConf video team could achieve this without ending up even
> more burnt out than we already are...

Understood. I think the way to make this happen is that people *not
currently involved* in the videoteam make it happen, and the videoteam
lets it happen :)

> Here's a bunch of problems I see with 'no video zones'. I'd be happy to
> talk about this some more if people have solutions we can implement that
> do no end up with us doing even more overworked that we currently are.
> 
> 1. Most of the people behind the cameras at DebConf are volunteers with
> very little training. To me it's a good things, since doing camera work
> is a very accessible way to volunteer during DebConf. Chances are, even
> if we had a 'no video zone', camera operators would end up doing pans
> over them.
> 
> I fear that would break trust, as people would feel safe in 'no video
> zones' and end up being on the streams and videos anyway.

I think what you said is a good description of this problem, so I think
part of "making it happen" is also making sure that everybody
understands this is done on best effort. If someone really really doesnt
want to be on video, they should not enter the room...

> 2. It's hard for the video team to guarantee 'no video zones' for
> logistical reasons. Often when we arrive at the venue during DebCamp, we
> don't know what the room layouts are and we have to deal with a bunch of
> surprises.

again, true. But still, 'no video zones' could be tried and could be a
stated goal. if it's impossible, it can be made clear.

> For example, in small BoF rooms it's nearly impossible not to capture
> the whole room in a single shot. The room is physically too small for this.

sure

> 3. We also have to 'build up' rooms in very little time (a few hours).
> This brings a layer of complexity to this problem, as most of the time
> the position of our cameras are not the result of well thought process.

true. but if considered from the beginning *and* considered *important*,
many things are possible.

On Sat, Aug 04, 2018 at 05:48:01PM +0200, Wouter Verhelst wrote:
> > Not having video pans of the audience since it doesn't necessarily
> > add
> > much value to the streams
> This is not correct. The audience is as much a part of the talk as the
> speaker is; otherwise we can just post videos of speakers speaking in
> an empty room.

Videos from the CCCongress *never* capture the audience, yet many many
people consider them deeply interesting.

And then, they also 'show' another problem: if I know the persons in the
audience asking questions well, I do recognize them by their voice, no
picture needed...


to sum up: me too would appreciate 'no video areas' in DebConf talk
rooms (*), and I would be willing to set up signs and markers to try to make
this happen. Please remind me next year in Curitiba! ;)

in that sense, I also applaud and thank to everyone who was relaying
questions from IRC...!

(*) I guess in (videoed) workshops 'no video areas' are not possible
indeed...


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Attachment: signature.asc
Description: PGP signature


Reply to: