Re: CRA and PLD vote status
> > The CRA and PLD proposals include regulations, that will be detrimental > > to free and open source software > > We've never had such a long option, and I'm worried this will break for > some people trying to vote when it gets wrapped to the next line. But it > might also just be fine. There is at least some code that only checks > the first few words or something like that. regulations in CRA and PLD proposals will be detrimental to FLOSS ? signature.asc Description: This is a digitally signed message part.
Re: new proposal: free and and non-free installers with SC change
On Wednesday, 14 September 2022 22:00:26 +07 Holger Levsen wrote: > hi, > > I'm looking seconds for this new proposal below, which is like > proposal E plus *also* offering free installer image. > > Rationale: we should keep producing fully freely distributable > Debian installer images, for those cases were some included non-free > stuff else might limit distribution, eg to Iran or Cuba etc or > by imposing other restrictions...! > > > - > Proposal F > > This ballot option supersedes the Debian Social Contract (a foundation > document) under point 4.1.5 of the constitution and thus requires a 3:1 > majority. > > The Debian Social Contract is replaced with a new version that is identical > to the current version in all respects except that it adds the following > sentence to the end of point 5: > > The Debian official media may include firmware that is otherwise not > part of the Debian system to enable use of Debian with hardware that > requires such firmware. > > The Debian Project also makes the following statement on an issue of the day: > > We will include non-free firmware packages from the "non-free-firmware" > section of the Debian archive on our official media (installer images and > live images). The included firmware binaries will normally be enabled by > default where the system determines that they are required, but where > possible we will include ways for users to disable this at boot (boot menu > option, kernel command line etc.). > > When the installer/live system is running we will provide information to the > user about what firmware has been loaded (both free and non-free), and we > will also store that information on the target system such that users will be > able to find it later. Where non-free firmware is found to be necessary, the > target system will also be configured to use the non-free-firmware component > by default in the apt sources.list file. Our users should receive security > updates and important fixes to firmware binaries just like any other > installed software. > > We will publish these images as official Debian media, alongside the current > media sets that do not include non-free firmware packages. > > --- > > (This is exactly "Proposal E" as found on > https://www.debian.org/vote/2022/vote_003 > now, except that in the very last sentence the word "replacing" has > been replaced with "alongside".) > > > Seconded. I signature.asc Description: This is a digitally signed message part.
Re: Changing how we handle non-free firmware
> > > = > > > > > > The Debian project is permitted to make distribution media (installer > > > images > > > and live images) containing packages from the non-free section of the > > > Debian > > > archive available for download alongside with the free media in a way > > > that the > > > user is informed before downloading which media are the free ones. > > > > > > = > > > > Wondering if this should be s/non-free section/non-free-firmware section/ > > Thanks for asking. The short answer is no. I kept my proposal very short, > keeping the focus on the smallest possible action we can do for helping those > users that need non-free firmware Thanks for your answer. What about not mentioning archive area and explicitly referring to firmware instead? "The Debian project is permitted to make distribution media (installer images and live images) containing packages with non DFSG compatible firmware ..." signature.asc Description: This is a digitally signed message part.
Re: Changing how we handle non-free firmware
> I hereby propose the following alternative text to Steve's original proposal. > > = > > The Debian project is permitted to make distribution media (installer images > and live images) containing packages from the non-free section of the Debian > archive available for download alongside with the free media in a way that the > user is informed before downloading which media are the free ones. > > = Wondering if this should be s/non-free section/non-free-firmware section/ signature.asc Description: This is a digitally signed message part.
Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification
> >> I think it would be clearer to add "that" between "confirm" and
> >> "their":
> >>
> >> {+ public, but developers will be given an option to confirm that
> >> their vote is included in the votes+} cast.
>
> Judit> I agree. It makes this option diverge a bit from the Option
> Judit> A it was forked from, but since the meaning is not changed it
> Judit> should be fine.
>
> Should I adopt the change as well or does it only make sense for ballot
> option 2?
As this part is identic in both ballot options, I'd say the change makes sense
for both.
signature.asc
Description: This is a digitally signed message part.
Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification
> I think it would be clearer to add "that" between "confirm" and "their":
>
> {+ public, but developers will be given an option to confirm that their
> vote is included in the votes+} cast.
I agree.
It makes this option diverge a bit from the Option A it was forked from,
but since the meaning is not changed it should be fine.
So unless one of the seconds object, the wording is changed to include "that".
signature.asc
Description: This is a digitally signed message part.
Re: GR Ballot Option: Allow, but do not require, secret voting
> > + At least 4K Developers have sponsored any single ballot > > option > > + which says the votes will be kept secret. I think, 4K puts the bar very high (that would require 20 people). signature.asc Description: This is a digitally signed message part.
Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification
I propose a ballot option for the GR
"Hide Identities of Developers Casting a Particular Vote"
that makes the following changes to the constitution.
1) Do not make the identity of a voter casting a particular vote public.
6) Codify that our election system must permit independent verification
of the outcome given the votes cast and must permit developers to
confirm their vote is included in the votes cast.
So it's the proposed GR minus the changes
not directly related to introducing secret votes.
I ask for seconds aka sponsors for this Option.
Rationale
=
Give the opportunity to vote for secret voting without needing to
additionally vote for unrelated/only slightly related
constitution changes;
for example for the change of mode of voting
from email to something not defined.
As it was mentioned in the discussion,
there might be no consensus on which options are direcly related -
This option regards the need to allow verification (6))
as directly related to secret votes, because otherwise
they would become completely unverifiable.
Summary of Changes
==
1) Do not make the identity of a voter casting a particular vote
public.
6) Codify that our election system must permit independent verification
of the outcome given the votes cast and must permit developers to
confirm their vote is included in the votes cast.
4.2. Procedure
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.
Votes are taken by the Project Secretary. Votes, tallies, and
results are not revealed during the voting period; after the
vote the Project Secretary lists all the votes {+cast in sufficient
detail that anyone may verify the outcome of the election from the votes cast.
The+}
{+ identity of a developer casting a particular vote is not made+}
{+ public, but developers will be given an option to confirm their vote
is included in the votes+} cast.
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.
necessary.
The next two weeks are the polling period during which
Developers may cast their votes. [-Votes in leadership elections are-]
[- kept secret, even after the election is finished.-]{++}
signature.asc
Description: This is a digitally signed message part.
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
> > I've also got concerns about batching up unrelated changes, with > > potentially controversial ones. And even if minor I'd prefer to see > > those debundled, even at the cost of additional GRs. > > If the only contentious point is the secrecy of votes, we could have an > amendment that includes all the other proposed changes, minus that one. I also agree with those, who speak against bundling. I'd like to be able to vote for something without needing to additionally vote for something else that is unrelated and I might even not want. If something is important enough to change the constitution for it, it's also important enough to have a separate vote on it. signature.asc Description: This is a digitally signed message part.
Re: What does FD Mean
> With the use cases of GRs coming to my mind (I certainly forgot some) I would > consider as useful to have the following standard options on each ballot: > > [... other options ... ] > > [ ] Further discussion > [ ] Do nothing, leave the question unresolved > [ ] None of the above > > > While I agree that we will never be able to put all options in every detail on > the ballots the basic choices above would remove a lot of stress and > uncertainty in the interpretation of FD. Wondering, what that would do to 'To vote "no, no matter what", rank "Further Discussion" as more desirable than the unacceptable choices'
