Hi,
intrigeri:
>> sajolida:
>>> In general, linking our presentation with work that might be most of
>>> interest to Mozilla or that we might ask them to support sounds like a
>>> good strategy to me; but not necessarily the only one of course.
>
> I'm coming back to this topic as the deadline is at the end of the
> month, and the last minute I can work on this is tomorrow (Sunday).
>
> The call for proposals says "Successful sessions are not lectures or
> presentations with slides, but are designed to challenge and encourage
> audience participation", which I hadn't noticed before. It gave me
> food for thought.
>
> Among what was proposed already on this thread, I think what would
> most easily fit in this format is one of Ulrike's ideas: "Contribute
> to Tails session (hands-on)". So I say if you want to propose and
> facilitate it, please go ahead. I'm personally not very motivated to
> facilitate this session there.
>
> OTOH it doesn't fit into the strategy sajolida proposed (quoted
> above).
Agreed. I would be happy to help on this session and I think it can be
really interesting for the audience we can expect to see in Mozilla
Festival. Even if it doesn't fit so much sajolida's strategy, I believe
it can still be a good point to make such a proposal, considering
Mozilla support on Tails. Ulrike, are you still willing to make such
proposal ? If so, I would be happy to proofread it etc.
> Personally this strategy is what motivates me most to
> facilitate a session there, so I see two options as far as I am
> concerned: either try to spin our (past & future) work on reproducible
> builds in a way that fits the format, which is going to be hard but
> I have a few ideas; or drop the ball and attend the event, if I can,
> without facilitating any session (and thus without a travel stipend
> from Mozilla).
>
> So far my best idea wrt. reproducible builds is to be much more
> general that "how we made the Tails ISO reproducible", and use our own
> use case as a mere example. There's lots of material ready to be used
> about why reproducible builds matter, and I have some ideas on top of
> that (e.g. the "I want software to do what I agreed it to do" angle,
> from the perspective of *consent* applied to technology, and why Free
> Software alone is not enough to allow me to give my informed consent).
> There's also a lot of material ready to be used about how to make
> software build reproducibly, and our own experience can illustrate
> this just fine. So I think we (e.g. myself and/or Ulrike) have the
> resources to facilitate a nice interactive session about this topic.
> It'll require non-negligible upfront preparation work though, e.g.
> looking at https://bugzilla.mozilla.org/show_bug.cgi?id=885777 in
> depth and ensuring we have an up-to-date understanding of the
> blockers: I assume that some attendees will be interested in "why
> isn't Firefox not reproducible?" (while Tor Browser is) in this
> context. I don't believe in making this session not-too-technical
> given the power imbalance between users and developers (that's
> possibly even greater in FOSS than in proprietary software, actually):
> even if we convinced users that they need/want reproducible builds,
> this would not change the world at all; instead, we need to convince
> developers and management to prioritize this.
>
Sounds really good for me, and a good way to fit sajolida's strategy and
leverage the MOSS experience in a way that could interest a lot Mozilla
people.
I am just wondering a bit about the balance you will have to make to
have the talk interesting for both developers and managers. I would
personally be in favor of trying to not be too much technical, but I
guess you already thought about it :)
As for Ulrich idea, I would be happy to proofread a proposal if you
write one, even if I don't think I would be of any help to prepare the
session.
Just a side note: I have been told that it is not uncommon that people
make more than one proposal in MozFest, so if you believe that both
proposals are relevant, and you have the energy to write them, there is
no need to choose only one. It can also be a good way to choose later if
we do both, or just one, according to whom is available.
Cheers,
--
geb
