Re: Interest in bidding on future Debian Conference

[Wouter Verhelst]

Hi Lisa,

Sorry for the late reply.

On Fri, Nov 24, 2023 at 01:24:18PM +, Lisa Goguen wrote:
>Hello,
> 
> 
>My name is Lisa Goguen and I work at Discover Halifax in Research and
>Business Development. I am writing to you today because we would love
>to have the opportunity to bring a Debian Conference to Halifax, Nova
>Scotia.
> 
> 
>We noticed that you are accepting proposals for 2024 and future years
>and have a few questions:
> 
> 
>Prior to reaching out to our local academia community, we wondered if
>it is possible to also submit a full proposal document or is the
>Debconf wiki format the only accepted format?

The wiki format is really the way to go.

Please note that DebConf is a non-profit conference. We rely strongly on
unpaid volunteers to do most of the work of organizing the conference,
and you should not expect to make a profit from it.

If you're aware of that, then great, but I thought I'd just point it
out; I get the impression you organize commercial events, and I wanted
to make sure that expectations were managed correctly (i.e., if you send
us an invoice at the end of the conference for labor etc, then both
sides will end up being very disappointed).

If my impression was wrong, then I apologize for misunderstanding you.
If you're still interested in placing a bid, then great! We'd love to
hear from you.

Thanks, and kind regards,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

FYI: Debian lanyards on the way to Kosovo

[Wouter Verhelst]

Hi,

I had a bunch of Debian lanyards (leftovers from dc15 and dc16, if I'm
not mistaken). Last week, I gave them to Kyle Robbertze (paddatrapper),
who is planning to attend. He said he will bring them along.

(I had planned too, originally, but cancelled for practical reasons)

Hope this is useful.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

FOSDEM conference organizing devroom

[Wouter Verhelst]

Hi folks,

(this will be my only email on the subject, promise!)

I've organized a devroom at the next FOSDEM on the subject of organizing
conferences. The idea is that with the state of the world as it is right
now, a lot of innovation has been happening in this space, and it might
be a good idea to compare notes with eachother.

That said, we don't want to limit ourselves to online workflows only,
and so tools and workflows for "regular" conferences and events are
definitely in scope too.

Is there anyone who would like to submit a talk on behalf of debconf?

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: The future of DebConf, online lessons from the pandemic [Was: Re: DebConf21 online, DebConf22 in Kosovo, DebConf23 in India, DebConf24 in Israel]

[Wouter Verhelst]

Hi Bernelle,

On Fri, May 14, 2021 at 02:35:00PM +0200, Bernelle Verster wrote:
> Online has significant advantages. The biggest challenge is the social bit.

I think the "social bit" is not to be underestimated. To me, the biggest
thing about debconf is not the talks, but the meeting of kindred spirits
in a social setting.

Just before my first debconf in 2005, I was getting demotivated working
on Debian; I had the feeling that what I was doing wasn't that
important, and that I should maybe just give up, and let other people
take care of things. Meeting so many like-minded people at debconf5, and
seeing the respect people were having for my m68k work at the time,
reinvigorated my passion for the project and meant I was more than happy
to continue doing things for Debian. I would be surprised if my
experience here was unique.

As another anecdotic piece of evidence, at debconf16's debcamp I was
working on fixing #796633. I got stuck at some point while doing this,
but then Tollef Fog Heen (who knew systemd better than me at the time)
sat down with me and helped me think things through, and we managed to
come up with a working solution in the end. I'm sure I would have been
able to figure out the issues by myself had I not been at debcamp. I'm
also sure it would have been in a time frame of months, rather than
days.

I understand (and support) the desire to have less global flights,
because global warming is a real thing and it is something we need to
work on if we're going to sustain life on our planet for the long term.
At the same time, for *Debian*, the effect of having a global,
in-person, meeting of minds has side effects for the project the reach
of which are not to be underestimated, and that we can't (yet?) replace
by a virtual meeting.

So while I'm all for improving our online debconf experience, and
believe we should use the new technologies we developed for the online
debconf to make our in-person debconfs more inclusive for people who
can't make it, I am absolutely also of the firm opinion that we should
continue to hold in-person debconfs, until the day comes where we can
create the same hallway track experience online that we have on
in-person debconfs.

Because to me, the hallway track of a debconf is way, way, *way* more
important than the talks. After all, I can watch talk recordings at
home, but I can't do hallway track meetings at home.

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Please contribute to the DebConf20 closing announcement

[Wouter Verhelst]

[Cc added to video team]

On Fri, Aug 28, 2020 at 07:27:34PM +0200, Laura Arjona Reina wrote:
> Dear all
> 
> I have started to draft the announcement about "DebConf20 closes":
> 
> https://salsa.debian.org/publicity-team/bits/-/blob/master/content/2020/debconf20-closes.md
> 
> Any help is welcome, in particular, short paragraphs explaining the
> specialities of this year (team sprints, language tracks, all the setup
> for the streaming and remote participation, the social events...).

Just a first stab at something involving the infra:

"When it became clear that DebConf20 was going to be an online-only
event, the DebConf video team spent much time over the next months to
adapt, improve, and in some cases write from scratch, technology that
would be required to make an online debconf possible. After lessons
learned from the MiniDebConfOnline in late May, some adjustments were
made, and then eventually we came up with a setup involving Jitsi, OBS,
Voctomix, SReview, nginx, Etherpad, and a newly written web-based
frontend for voctomix as the various elements of our stack.

All components of the video infrastructure are free software, and the
whole setup is configured through our public ansible at
."

Video team: did I miss anything? If so, please speak up.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Photo permission checkbox

[Wouter Verhelst]

On Sun, Jul 19, 2020 at 01:07:49PM +0200, Aigars Mahinovs wrote:
> Hello,
> 
> I am considering assembling a Debconf20 group photo from participant mugshot
> photos in our registration system.

I'd been thinking about that, too. It might be nice to create a photo
mosaic of the debconf20 logo or something along those lines...

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Sponsor loop

[Wouter Verhelst]

Hi folks,

I've started looking at creating a sponsor loop and credit rolls for the
video team.

Can someone please tell me which logos should appear on them?
Preferably, with links to the actual logos ;-)

Thanks,

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

DebConf lanyards

[Wouter Verhelst]

Hi,

A bunch of Debconf lanyards from dc16 in Cape Town have ended up at my
place. I can bring them to FOSDEM.

Is anyone interested in taking them from me? They might be useful to
take to dc19.

Thanks,

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Photo policy for DebConf

[Wouter Verhelst]

On Sat, Aug 04, 2018 at 03:41:36PM -0400, micah anderson wrote:
> Wouter Verhelst  writes:
> 
> > As a member of the video team, I would strongly object to such a policy.
> > There is nothing more annoying than hearing a question on a video but
> > not seeing the speaker.
> 
> There are plenty off things that are more annoying than that: audio not
> working, video playing something other than it should, a distracting
> monkey swinging around and making noises.

Well, yes, but not when we only consider the things that are likely to
happen in a Debconf video. The first does indeed happen sometimes, and
is annoying, but usally fixed after a few tries. The second and third,
not quite.

> I can think of more, but I think you are just being hyperbolic.

No, in fact, I was being serious.

> I watched Debconf videos, and have in the past. I have *never* been
> annoyed at hearing a question on a video and not seeing the speaker. Not
> a single time. If I can hear the question, I don't care what the person
> looks like.

We'll have to agree to disagree on that part then, I suppose.

> In fact, every time the video team tries to quickly capture the person
> asking the question, it just makes me seasick.

That does happen and is unfortunate, indeed. We do try to avoid it, and
our training warns people not to make sudden movements in such cases.
But I do think it's reasonable for people to want to know who the person
asking a certain question is, and that can only happen if they are
captured on camera.

DebConf videos are an important resource to the community; while I think
it is reasonable for people to participate to events by proxy, or to
prefer to talk to a speaker after the recorded part of a video has
finished, I do not think that it is reasonable for them to request to
remain out of the camera's eye *if they are actively participating in a
session*.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Photo policy for DebConf

[Wouter Verhelst]

On Sat, Aug 04, 2018 at 03:38:29PM -0400, micah anderson wrote:
> Wouter Verhelst  writes:
> 
> > On Sat, Aug 04, 2018 at 04:56:00AM +, Ulrike Uhlig wrote:
> >> Furthermore, I would like to see a policy in which BoFs may be
> >> explicitly choses by the participants to be no-photo zones, on top of
> >> being marked as "non-recorded".
> >
> > No.
> 
> Yes.

No.

> > Anything which requires a photographer to check a list at the moment of
> > the photo just does not work. A good photo often can only be taken in a
> > split second; to have to check a list if person X is happy with it, or
> > if the event in room Y at time Z is okay would kill the moment.
> 
> You don't need a list. You can just say "Anyone mind if I take photos?"

That I can agree with, but that is not what was being suggested above.

Let me make absolutely clear: I do not agree that photos should be
allowed to be taken of people without consent. That is... horrible. If
the rule is "you must always explicitly ask for consent before taking a
photo", then fine, that is a reasonable rule. It wouldn't work for me
(because the photos I like to take require that the subject does not
know he/she is being photographed, and that doesn't work if you must ask
consent first), but it is a reasonable rule, and I would abide by it (if
only by leaving my camera at home).

But that is not what Ulrike was suggesting.

> and if nobody minds, then you are fine. Its really easy. Overengineering
> this process, with lists, lanyards and no-photo zones is absurd, you
> simply need to use old-fashioned human communication. 

Lanyards allow for consent to be given in an implicit way, and allow for
the kind of unexpected photos that I like to take, without encroaching
on the personal preference of people who would prefer not to be
photographed.

I think it is an excellent compromise between both sides of the
argument.

> I've been to many events where this is the policy and it is not
> complicated, and not a burden on the photographer. Its as simple as
> communicating between humans.

Sure, but it is a pity for certain options -- and it is not what was
being suggested earlier, and which is the thing I was saying "no" to.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Photo policy for DebConf

[Wouter Verhelst]

On Sat, Aug 04, 2018 at 01:35:26PM -0500, Gunnar Wolf wrote:
> Wouter Verhelst dijo [Sat, Aug 04, 2018 at 05:38:24PM +0200]:
> > On Sat, Aug 04, 2018 at 04:56:00AM +, Ulrike Uhlig wrote:
> > > Furthermore, I would like to see a policy in which BoFs may be
> > > explicitly choses by the participants to be no-photo zones, on top of
> > > being marked as "non-recorded".
> > 
> > No.
> > 
> > Anything which requires a photographer to check a list at the moment of
> > the photo just does not work. A good photo often can only be taken in a
> > split second; to have to check a list if person X is happy with it, or
> > if the event in room Y at time Z is okay would kill the moment.
> 
> My take on this? Just take the picture. But, if you take pictures of a
> group, you have the responsibility to review them, and discard any
> pictures that have on them people who have opted out.
> 
> Is your photo a treasure? Well, then it falls upon _you_ to contact
> all of the pictured people that have a no-photos policy. Show them
> your great, beautiful shot. And, if they insist on your photo not
> being public, it has to become private.
> 
> If they insist on the photo being destroyed, you are not allowed to
> keep it.

This is a lot of administration, when it can be made much easier with a
simple lanyard, as was suggested.

I'm not saying people should be taken photos of without consent. Consent
should be given, whether implicitly or otherwise. But having to hunt
down everyone after the fact to request this consent may be a lot of
work, especially for people who take a lot of photos. If it is obvious
whether consent is there *at the time of the photo*, then this will be
better for photographers (because they don't need to worry about hunting
down people for consent), and for people who dislike being on photos
(because they won't be bothered with photos to say "no" to, and can rest
assured that their photo won't be distributed without their consent).

> > If you do not want to be on a photo, a lanyard idea (which applies to a
> > small group of people only) seems like a good idea; it allows a
> > photographer to see, while taking the photo, that there is one person in
> > that photo who would prefer not to be photographed, and they can
> > proceed. Obviously this would not work when the group of people is large
> > (like a photo in the hacklab of everyone in the room; you cannot
> > reasonably expect photographers to check everyone in a room with 100
> > people before taking a photo).
> 
> Agree. That's why I talked about the small, focused, personal groups
> vs. the large, impersonal, general photos. Of course, the boundary
> might not be as clear-cut as we want it...

Unfortunately, this is true. I think the boundary would be "people who
would be named by any person when asked 'who is on this photo'". If you
are, then you are the subject of the photo and you should have given
consent. If you are not, then you are in the background and should not
give consent.

This is a difficult decision to make, and I suspect we may have a few
misunderstandings there; but if we can make it work, I would prefer
something along those lines.

> > A room which is explicitly marked as "no photos in this room please"
> > would work too. You can have signs at the entraces to that room, and
> > anyone going in would know to leave their cameras at the door (or, at
> > least, to switch them off).
> > 
> > But to have some BoFs marked as "photos okay", and then the next BoF in
> > the same room be marked as "photos not okay" is just unworkable, and
> > effectively forbids photos alltogether.
> 
> If people not wanting to be photographed want to be a part of a BoF
> for which the facilitator is OK with photos, they should be able
> to.

I agree with that.

> If they want to participate during the BoF, they will either
> proxy,

I think this is fine.

> or allow their voice (but not image) to be streamed.

In my personal opinion, this is not fine, but I respect that not
everyone thinks the same way about this.

> It is, yes, taxing on video-team, and training (even better, explicit
> technical impossibility if workable!) must ensure that they don't
> capture the forbidden area of the room.
> 
> It is not that one BoF accepts photos and another does not - It is
> about each _person_.

Yes, but that is not what the suggestion was about. The suggestion was
to make a rule that some BoFs accept photos, and some BoFs do not. The
net result of that would be that you would be allowed to take a photo
one moment, and then the next moment -- when the next BoF starts -- you
would not, because... rules? Or something.

This is unworkable

Re: Photo policy for DebConf

[Wouter Verhelst]

On Fri, Aug 03, 2018 at 08:40:59AM +0800, Paul Wise wrote:
> Ulrike Uhlig wrote:
> 
> > it has been pointed out to me that there *is* a photo policy for
> > DebConf within the code of conduct.
>
> 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.

Specifically to this, some talks are just long stretches of speakers
speaking with few or no slides. Just recording the speaker in such
instances will often make the recording boring; having audience pans in
such cases keeps the recording after the fact interesting, and will
massively improve the usefulness of the video.

> 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.

As a member of the video team, I would strongly object to such a policy.
There is nothing more annoying than hearing a question on a video but
not seeing the speaker.

If you prefer not to be recorded on a talk video, you are welcome to not
participate. I think it is totally fair that if you're in a talk which
will be recorded, you may end up on the recording -- especially if you
actively participate in the session.

If the lanyard suggestion is implemented, I suppose it would be
reasonable to request that the audience camera does not take close-ups
of people who wear a "do not photograph" lanyard and who do not actively
participate in the session. But while I can respect the desire to not be
photographed, even though I do not share such a desire, there is value
in videos being complete -- and that makes it impossible to allow people
who do not want to be on the video to participate in certain ways.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Photo policy for DebConf

[Wouter Verhelst]

On Sat, Aug 04, 2018 at 04:56:00AM +, Ulrike Uhlig wrote:
> Furthermore, I would like to see a policy in which BoFs may be
> explicitly choses by the participants to be no-photo zones, on top of
> being marked as "non-recorded".

No.

Anything which requires a photographer to check a list at the moment of
the photo just does not work. A good photo often can only be taken in a
split second; to have to check a list if person X is happy with it, or
if the event in room Y at time Z is okay would kill the moment.

If you do not want to be on a photo, a lanyard idea (which applies to a
small group of people only) seems like a good idea; it allows a
photographer to see, while taking the photo, that there is one person in
that photo who would prefer not to be photographed, and they can
proceed. Obviously this would not work when the group of people is large
(like a photo in the hacklab of everyone in the room; you cannot
reasonably expect photographers to check everyone in a room with 100
people before taking a photo).

A room which is explicitly marked as "no photos in this room please"
would work too. You can have signs at the entraces to that room, and
anyone going in would know to leave their cameras at the door (or, at
least, to switch them off).

But to have some BoFs marked as "photos okay", and then the next BoF in
the same room be marked as "photos not okay" is just unworkable, and
effectively forbids photos alltogether.

I can imagine people who do not like to be photographed might think that
this is okay, but it is not; photos are an important way to show what
happens at an event to the world, and we do need them, if only for the
sponsorship report at the end of a debconf.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Saddened by the amount of events in video-equipped rooms which are not recorded

[Wouter Verhelst]

Hi Phil,

On Thu, Aug 02, 2018 at 11:01:58AM +0200, Philip Hands wrote:
> Wouter Verhelst  writes:
> 
> > Hi team!
> >
> > Since a few years, debconf has given speakers the ability to mark a talk
> > as one that should not be recorded on video. Such talks sometimes get
> > scheduled in rooms with video equipment.
> >
> > As a member of the FOSDEM organisation, which has an official policy of
> > "if you want it to happen at FOSDEM, you MUST consent to it being
> > recorded on video", I must say I am disheartened by this. Having a talk
> > or BoF be on camera is often useful for various reasons:
> >
> > - It allows remote participation by those of us not lucky enough to make
> >   it to the DebConf in question;
> > - It creates a record of what has been said in the talk, which can be
> >   useful to refer to after the fact;
> > - It allows people for who English is not a first language to replay the
> >   video a few times until they understand what is happening, and/or for
> >   things to be subtitled so that they can follow what's happening in
> >   their native language (this latter doesn't happen as often as we'd
> >   like currently, but we do have a setup for subtitling).
> > - If you want to be at two talks or BoFs which happen at the same time,
> >   you can go to the one talk in the knowledge that you'll always be able
> >   to watch the video of the other one.
> >
> > While I can understand that sometimes there may be reasons for things
> > not to be recorded, I think that in service of the greater Debian
> > community, DebConf should try to make as many events as possible be
> > public; that is, we should make things recorded by default, not by the
> > whim of the speaker/facilitator of the talk or BoF.
> >
> > It's obviously way too late for this to happen right now anymore, but
> > I[1] would like to suggest that for next year, submission procedures are
> > changed so that:
> >
> > - The form where talk submissions can be made is, if necessary, changed
> >   so that things will be recorded by default, unless the speaker
> >   explicitly requests otherwise;
> > - It is made clear that "I don't think this would be useful" is not
> >   in and of itself a good enough reason (other people might reasonably
> >   disagree with that position);
> > - If a speaker requests that a talk not be recorded, we ask them to
> >   explain why they request that, so that if the request is based on a
> >   misunderstanding of what that would entail practically this can be
> >   cleared up;
> > - Talks which are marked as not recorded will by default be scheduled in
> >   rooms which have no video content, so that if the not to be recorded
> >   talk is marked so for privacy reasons, we don't have to worry about
> >   video equipment being left on by mistake, and so that talks which
> >   might otherwise have been usefully recorded can still be scheduled in
> >   a room with the necessary equipment.
> >
> > Thoughts?
> 
> I know that some of them were specifically requested to be without
> recording, so I suppose there is no reason to put them in a different
> room if that was going to leave the room empty.

My point is that sometimes this is requested when it would not have been
necessary. The fact that they are specifically requesting that seems
wrong to me, at least in some cases.

> Also, the ad-hoc sessions do not get video coverage, as a matter of
> policy.

I believe this policy was set because the video team cannot be expected
to provide video coverage at extreme short notice. That however
shouldn't mean we can't provide any coverage for ad-hoc sessions if they
were requested quite well in advance...

In addition, like Andreas already said, it should be the responsibility
of the scheduling and/or video team to decide whether or not video
coverage can be done in that case, not of the speaker.

> Is what you're seeing (or rather not seeing ;-) ) actually an
> articact of there being a lot of ad-hoc sessions?

Possibly, but some of the sessions have been there for quite a while.

> Perhaps we need to re-examine that policy, or the reason for there being
> a lot of ad-hoc sessions in that case?

That might work too, yes; but I don't think that negates (all of) the
things I said above.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: DebConf18 meeting minutes @FOSDEM2018

[Wouter Verhelst]

Hi,

On Thu, Feb 08, 2018 at 01:01:06AM +0100, Hector Oron wrote:
> 0. Video team support (global: paddatrapper, stefano; local: Mwei)
>   - paddatrapper is going to do checklist of items video team needs
> to be passed to local team member to work on it.
>   - budget in shipping video hardware to Taiwan.
>   - take presentation room pictures
> - we need to know where is electrical power plugs (take a pic)
> - we need to know audio/video (A/V) room setup (take a pic)
>   - 10TB storage for videos (10 Gbps link)
>   - Server for encoding (>= 24 cores, VM ok)

For clarity: this may be multiple servers or VMs too, the encoding
software is capable of running on multiple nodes. Having said that,
virtualisation slows the transcoding down somewhat (especially the I/O
heavy bits of it), so it may be preferable to have bare material options
if they are available.

(we're using the same encoding software for FOSDEM, where it runs on 2
"storage" plus one "master" plus five "encoder slave" nodes all from the
same IaaS provider)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab