Hi all,
Moving this into a separate thread from all the discussion for a bit more visibility.
Thank you for all the discussion over the past couple of days about my
proposal and about possible rewordings to point 5 of the Social Contract.
The short summary is that, after considering that feedback, I'm going to
stick with the current wording for proposal E for this vote.
I see a clear desire to reword point 5 of the Social Contract to get rid
of some obsolete language and possibly tighten and clarify it, but I also
think it's somewhat orthogonal to the current GR. Therefore, I'm going to stick, for this GR, with making what I think is the minimal change
required to make proposal A clearly consistent with the Social Contract,
and then will look at starting a separate GR to update SC point 5 based on
the outcome of that vote.
Here's my rationale:
* I was reluctant to propose a ballot option in part because I don't have
a lot of time at the moment to spend on this discussion. There was a
lot of great feedback about how to reword point 5, and I very quickly
ran out of time to absorb it and iterate. This argues for not trying to
do that now with me as the proposer, given my constraints.
* At least one person has already said that they would like to see SC5
reworded, but also would prefer a ballot option other than proposal A
(and my proposal E, which is identical but with the SC change added).
This is concrete evidence that these changes are orthogonal, and rather
than put the combinatorial explosion on the ballot, I think it's best to
stick with the minimum change relevant to this GR and move the rewording
to a separate GR.
* I'm in general opposed to trying to do changes to foundation documents
quickly. We're in the last few days of an already-extended discussion
period and coming up quickly on a vote. Now is the time to stop
changing things about what we're voting on. If we move larger changes
to the SC to a separate discussion, I can post some early drafts, we can
have preliminary discussions among the most interested to hash out
wording, people can prepare alternatives in advance, and then we can
enter a fresh discussion period with more groundwork laid and more of
the initial discussions hashed out, which is how I'd prefer to handle
it.
The way I see it is that this GR is primarily intended to provide project guidance to the team working on the installer and installation media, at
their explicit request, on how to handle non-free firmware. I think the options already on the ballot provide a good range of possible decisions
the project can make and directly address that request. We can decide, as
part of that vote, whether to give explicit SC guidance that the installer
can be partly non-free, or not, which is directly relevant. Then, once
that's decided, we'll largely know what we want SC5 to say in terms of practical effect, and we can have a separate discussion on the best way to
say it.
Steve's suggestion of dropping the explicit contrib and non-free wording
from SC5 as part of my ballot option is more borderline, since that's also directly relevant to this GR, but I'm going to err on the side of not
changing things and stick with my belief that the existing language
implicitly allows for multiple non-free sections. If it becomes relevant
by my proposal winning, we can then clean up the language in the
subsequent GR.
Hope this makes sense to everyone, and of course if anyone thinks I'm
making a big mistake, I'm very open to hearing that.
--
Russ Allbery (
rra@debian.org) <
https://www.eyrie.org/~eagle/>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)