Re: Renaming the FTP Masters

[Thomas Goirand]

On 11/11/21 8:48 PM, Bastian Blank wrote:
> On Thu, Nov 11, 2021 at 02:23:58PM -0500, Daniel Kahn Gillmor wrote:
>> I'm legitimately surprised to hear that anyone in the Debian project
>> believes that the term "FTP master" is *not* confused and outdated.
> 
> I'm really surprised that ftp master is more important than the weird
> definition of DD and DM.
> 
> Bastian
> 

Wrong wrong wrong ... we're "project members" ... don't you remember? :)
Just like AH is now CT. (Gosh, DMT TLA...)

This shows that it will take years, if not decades, for the rename to
ever be effective (if the person(s) in charge decide(s) it...).

Cheers,

Thomas Goirand (zigo)

Re: Renaming the FTP Masters

[Jonathan Carter]

On 2021/11/11 21:48, Bastian Blank wrote:

I'm really surprised that ftp master is more important than the weird
definition of DD and DM.


You left out "non-uploading DD" :)

-Jonathan

Re: Renaming the FTP Masters

[Salvo Tomaselli]

I feel that the benefits and costs estimate are just made up numbers.

I'd like to know if there exists a person in the whole world that would
refuse to cooperate with Debian because of the FTP master name. My totally
made up answer is no. But I could of course be totally wrong.

Best

Il gio 11 nov 2021, 20:48 Felix Lechner  ha
scritto:

> Hi,
>
> On Thu, Nov 11, 2021 at 10:28 AM Bdale Garbee  wrote:
> >
> > being a good
> > citizen of a community like Debian means *not* side-stepping such
> > responsibilities.
>
> No sweat. How about the following?
>
> $500,000 Value of friendly and up-to-date team names [1]
> $200,000 Cost of implementation [2]
> 
> $300,000 Net benefit to Debian
>
> Please consider, however, that no individual opinion—and especially
> not mine—can stand for the group's preferences. As the proposer, I am
> biased. Why argue?
>
> > the workload you
> > may be imposing on others by taking something to a project-level vote
>
> Voting is a right. [3] Advocates help with the process. The project
> imposes decisions by approving or rejecting resolutions. [4]
>
> Kind regards
> Felix Lechner
>
> [1] Recruiting 50 excess contributors over ten years, at a lifetime
> contribution of $10,000 each.
> [2] 2,000 hours of work at $100, a rate roughly in line with
> https://www.debian.org/consultants/
> [3] https://en.wikipedia.org/wiki/Universal_suffrage
> [4] Section 2.1, https://www.debian.org/devel/constitution
>
>

Re: Renaming the FTP Masters

[Jonathan Carter]

Hi Marc

On 2021/11/11 17:29, Marc Haber wrote:

On Wed, Nov 10, 2021 at 05:37:55PM -0500, Daniel Kahn Gillmor wrote:

PS For people who are concerned that a retreat from the term "master" is
somehow the language police run dangerously amok, it's worth asking
why you feel so committed to the term "master" that you would fight
to keep the project we all work on using terminology

>

there might be people who would oppose the change not because they're
comitted to the term "master" but they feel that we have darn more
important things to do - for example re-gaining technical excellence and
leadership. We haven't been concentrating on technology enough in the
last years.


Well, I would tell these hypothetical persons that you're concerned 
about that technical excellence and project maintenance go hand in hand, 
and that you can't have one without the other. On the scale of how large 
a project change is in terms of changes that we need to make in Debian, 
this one is really on the smaller end of the scale. There's a lot of 
work that I've been wanting to push, but I've been patient because we 
had the release this year, then DebConf, now we have a GR about GRs, and 
it is probably starting to sound that I'm complaining about these, but 
I'm not, it's just that making changes- especially changed in Debian, 
takes time and patience, but they are necessary, and they do not need to 
block technical work. We do have some serious project-level maintenance 
backlog, part of my DPL campaign for this year was to help address that. 
We didn't explore that in too much detail during the voting period, but 
I do expect that we'll have quite a few decisions coming up that will be 
significantly more complicated than a team name change, and I hope that 
we can figure out ways to make sure that everyone is heard and that we 
don't impede on anyone's work while figuring it all out. But we have to 
try, we cannot allow project rot to just continue and risk it spreading 
into other areas.


-Jonathan

Re: Renaming the FTP Masters

[Felix Lechner]

Hi,

On Thu, Nov 11, 2021 at 10:28 AM Bdale Garbee  wrote:
>
> being a good
> citizen of a community like Debian means *not* side-stepping such
> responsibilities.

No sweat. How about the following?

$500,000 Value of friendly and up-to-date team names [1]
$200,000 Cost of implementation [2]

$300,000 Net benefit to Debian

Please consider, however, that no individual opinion—and especially
not mine—can stand for the group's preferences. As the proposer, I am
biased. Why argue?

> the workload you
> may be imposing on others by taking something to a project-level vote

Voting is a right. [3] Advocates help with the process. The project
imposes decisions by approving or rejecting resolutions. [4]

Kind regards
Felix Lechner

[1] Recruiting 50 excess contributors over ten years, at a lifetime
contribution of $10,000 each.
[2] 2,000 hours of work at $100, a rate roughly in line with
https://www.debian.org/consultants/
[3] https://en.wikipedia.org/wiki/Universal_suffrage
[4] Section 2.1, https://www.debian.org/devel/constitution

Re: Renaming the FTP Masters

[Bastian Blank]

On Thu, Nov 11, 2021 at 02:23:58PM -0500, Daniel Kahn Gillmor wrote:
> I'm legitimately surprised to hear that anyone in the Debian project
> believes that the term "FTP master" is *not* confused and outdated.

I'm really surprised that ftp master is more important than the weird
definition of DD and DM.

Bastian

-- 
There's another way to survive.  Mutual trust -- and help.
-- Kirk, "Day of the Dove", stardate unknown

Re: Renaming the FTP Masters

[Daniel Kahn Gillmor]

On Thu 2021-11-11 07:56:24 -0500, Roberto C. Sánchez wrote:
> 1/ The assertion "we all can acknowledge is confused and outdated" is
>far fom the case.  This and other discussions on the matter are
>strong evidence that "we can all acknowledge" is a
>mischaracterization.

I'm legitimately surprised to hear that anyone in the Debian project
believes that the term "FTP master" is *not* confused and outdated.

There is some subset of people who think that "master" is confused and
outdated.

There is another subset of people who think that "FTP" is confused and
outdated.

Some of us are in the intersection of those subsets.

I had expected the union of those sets to be congruent with the entire
project membership, thus i would have thought everyone would be able to
get behind a rename of the team in accordance with the wishes of the
team members themselves.

Live and learn, I guess.  You've made it pretty clear that you're not in
the "master" subset.  But I'm surprised to hear that you also are not in
the "FTP" subset.

On the off chance that you *are* in the "FTP" subset, i encourage you
re-read my earlier postscript in that light.

This is my last message on this thread.

--dkg


signature.asc
Description: PGP signature

Re: Renaming the FTP Masters

[Bdale Garbee]

Felix Lechner  writes:

> Hi,
>
> On Thu, Nov 11, 2021 at 5:12 AM Roberto C. Sánchez  wrote:
>>
>> Those proposing
>> improvements must also demonstrate how the claimed improvements
>> provide greater benefit than the cost incurred in implementing the
>> improvements.
>
> I had hoped to sidestep that responsibility by putting the matter to a
> vote.

Reading this really bothers me.  The problem I see is that being a good
citizen of a community like Debian means *not* side-stepping such
responsibilities.

Because everyone here is a volunteer, it's important to not make being
part of Debian less rewarding in unnecessary ways.  When you have a good
idea that needs effort by others to implement, how you choose to go about
proposing they make that effort matters.  If you can successfully
convince that individual or group that your idea is a good one and they
come to *want* to do the work, we all win and our community becomes
stronger. 

When you side-step the responsibility of considering the workload you
may be imposing on others by taking something to a project-level vote as
the first step, those people are likely to feel "forced" to do the work.
In my experience, that makes it *less* likely the work will actually get
done, or be done in a timely manner.

Bdale


signature.asc
Description: PGP signature

Re: Draft GR for resolution process changes

[Timo Röhling]

* Russ Allbery  [2021-11-11 08:26]:

Once a proposal has been sponsored and added to the ballot, we, as a
general social convention, stop sponsoring it unless it feels particularly
important to be listed as a sponsor.  That means that any given option
currently on the ballot usually has "hidden" support in the form of
Developers who intend to vote for it but haven't sponsored it.  It seems
likely that in some situations those Developers may think "okay, the
opinion I really cared about is on the ballot so I can vote the way I
want" and then may tune out the subsequent discussion.

In other words, I think once a ballot option makes it onto the ballot, the
rules are attempting to capture the sense that it no longer belongs just
to its proposer, but now represents some unknown number of people who want
to vote for it.

Given that, if the proposer changes their mind and wants to propose a
substantially different ballot option, I think the default should be that
the proposer do that as a separate ballot option and get sponsors for that
new ballot option (and possibly withdraw as the proposer for the original
ballot option).  This reflects the fact that just because the proposer
changed their mind, that doesn't mean that other supporters of that ballot
option also changed their minds.

As Sam says, the ability to make substantive changes if all sponsors agree
is essentially an optimization.  It's tedious to propose a new option,
have everyone sponsor it again, withdraw as proposer of the old option,
and confirm that no one else is stepping forward, so for changes that
everyone agrees make the ballot option better, we should have a way to
allow those to be made more easily.  But we want some sort of check that
this is really true and not just take the proposer's word for it, so we in
essence draft the sponsors of the ballot option as referees to decide
whether this change does make sense in the context in which they
originally supported that option.

I must say I find your reasoning convincing. A certain stability of
ballot options is desirable, and as our voting scheme does not
suffer from spoiler effects, we can afford to keep the odd stale
option. Besides, as you pointed out, the original proposer can
always formally withdraw and ask their sponsors to do the same; if
there is hidden support, it will either materialize or the option
will be discarded; no additional procedural rules required.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Draft GR for resolution process changes

[Russ Allbery]

(cc'ing Charles since I'm not sure if he's reading all of debian-vote; let
me know if this is annoying and I should stop.)

Sam Hartman  writes:

> It sounds like what russ and Charles are talking about is the following:

> * You as a proposer want to accept an amendment

> * A sponsor objects, and so you can't even though you would have been
>   able to if you had fewer sponsors.

> I have an alternate proposed fix:

> If the proposer accepts the amendment and there are k sponsors who have
> not objected, the amendment is accepted.
> (I think it's okay even if we end up counting new sponsors to get to k
> who have not objected)

This and Timo Röhling's similar idea were very helpful for thinking
through this.  Thank you!

After pondering this for a couple of days, I'm going to advocate for not
making a change here, even though it looks a bit restrictive.  I think the
key point is this analysis:

> But under Russ's approach, the whole amendment process is really just a
> convenience to make it easier to update an option with less withdrawing
> and re-proposing.

I arrived at a somewhat different conclusion given that point, though,
because I think there's a principle of ballot stability here that's worth
maintaining.  Here's my argument:

Once a proposal has been sponsored and added to the ballot, we, as a
general social convention, stop sponsoring it unless it feels particularly
important to be listed as a sponsor.  That means that any given option
currently on the ballot usually has "hidden" support in the form of
Developers who intend to vote for it but haven't sponsored it.  It seems
likely that in some situations those Developers may think "okay, the
opinion I really cared about is on the ballot so I can vote the way I
want" and then may tune out the subsequent discussion.

In other words, I think once a ballot option makes it onto the ballot, the
rules are attempting to capture the sense that it no longer belongs just
to its proposer, but now represents some unknown number of people who want
to vote for it.

Given that, if the proposer changes their mind and wants to propose a
substantially different ballot option, I think the default should be that
the proposer do that as a separate ballot option and get sponsors for that
new ballot option (and possibly withdraw as the proposer for the original
ballot option).  This reflects the fact that just because the proposer
changed their mind, that doesn't mean that other supporters of that ballot
option also changed their minds.

As Sam says, the ability to make substantive changes if all sponsors agree
is essentially an optimization.  It's tedious to propose a new option,
have everyone sponsor it again, withdraw as proposer of the old option,
and confirm that no one else is stepping forward, so for changes that
everyone agrees make the ballot option better, we should have a way to
allow those to be made more easily.  But we want some sort of check that
this is really true and not just take the proposer's word for it, so we in
essence draft the sponsors of the ballot option as referees to decide
whether this change does make sense in the context in which they
originally supported that option.

Given that, I lean away from setting the bar for modifying a ballot option
the same as the bar for proposing a new option on the grounds that, once
on the ballot, I think options should be stickier than that and the bar
for changing them should be higher.  The sponsors are, in effect,
representing that unknown group of people who were satisfied by that
option and may not be paying attention, so it should be hard to change an
option in a way that may be incompatible with those preferences and, in
the event of any conflict, the default should be to draft a new option.
(But we don't go as far as letting any Developer object, like we do for
the trivial changes provision, because involving people who would never
have voted for the option anyway is less likely to be constructive.)

I believe there is a real bug in the existing constitution in that it at
least implies that someone could sponsor a ballot option solely to then
object to a proposed change to it, which I don't think we want.  I mostly
fixed that bug by requiring people have already sponsored the option
before the change was proposed if they want to object.  But after thinking
about this some more, I don't think we want to go farther.  Once people
who have sponsored the original ballot option start objecting, I think we
should take that as concrete evidence that the new option is sufficiently
different that it may not represent the people who were supporting the old
option, and we should therefore default to adding the new option via the
normal mechanism.

Does that make sense to everyone?

-- 
Russ Allbery (r...@debian.org)  

Re: Renaming the FTP Masters

[Marc Haber]

Hi,

On Wed, Nov 10, 2021 at 05:37:55PM -0500, Daniel Kahn Gillmor wrote:
> PS For people who are concerned that a retreat from the term "master" is
>somehow the language police run dangerously amok, it's worth asking
>why you feel so committed to the term "master" that you would fight
>to keep the project we all work on using terminology

there might be people who would oppose the change not because they're
comitted to the term "master" but they feel that we have darn more
important things to do - for example re-gaining technical excellence and
leadership. We haven't been concentrating on technology enough in the
last years.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Renaming the FTP Masters

[Roberto C . Sánchez]

On Thu, Nov 11, 2021 at 02:22:48PM +0100, Pierre-Elliott Bécue wrote:
> 
> Roberto C. Sánchez  wrote on 11/11/2021 at 13:56:24+0100:
> > If we as a project allow some to make changes without considering the
> > concerns of those affected by the changes, we are not being faithful
> > to our own principles.
> 
> That's true, but it doesn't look like it's what's being done here.
> 
> Felix proposed something, and it's being debated. In particular it seems
> most agree that a GR is not an appropriate idea, but rather let
> FTPMaster Team and the DPL convey and find a path if it's relevant.
> 
> Apart from that, we were many to raise the opinion that removing the
> "master" term out of "it reminds slavery" motive was not something we
> thought sane.
> 
> IOW, it seems, to me, that the project does quite efficiently what is
> expected on these grounds. Opinions are expressed and the discussion
> goes on.
> 
> Mind, it's not even close to a flame, so it's actually quite nice!
> 
I agree with you completely.

My words that you quoted were specifically responding to DKG's words:

> > > If someone is excited to improve the project, even if you don't
> > > have the capacity to help them do it, at least *let* them do it!

This seems to imply that objecting to a proposed change is inherently an
obstructionist act.

I haven't expressed an opinion on Felix's initial GR suggestion, but the
discussion that has arisen from it so far seems to have allowed those on
various sides of the matter express their ideas and concerns.  That
seems to be what we as a project value.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Renaming the FTP Masters

[Pierre-Elliott Bécue]

Roberto C. Sánchez  wrote on 11/11/2021 at 13:56:24+0100:
> If we as a project allow some to make changes without considering the
> concerns of those affected by the changes, we are not being faithful
> to our own principles.

That's true, but it doesn't look like it's what's being done here.

Felix proposed something, and it's being debated. In particular it seems
most agree that a GR is not an appropriate idea, but rather let
FTPMaster Team and the DPL convey and find a path if it's relevant.

Apart from that, we were many to raise the opinion that removing the
"master" term out of "it reminds slavery" motive was not something we
thought sane.

IOW, it seems, to me, that the project does quite efficiently what is
expected on these grounds. Opinions are expressed and the discussion
goes on.

Mind, it's not even close to a flame, so it's actually quite nice!

With best regards,

--
PEB


signature.asc
Description: PGP signature

Re: Renaming the FTP Masters

[Felix Lechner]

Hi,

On Thu, Nov 11, 2021 at 5:12 AM Roberto C. Sánchez  wrote:
>
> Those proposing
> improvements must also demonstrate how the claimed improvements
> provide greater benefit than the cost incurred in implementing the
> improvements.

I had hoped to sidestep that responsibility by putting the matter to a vote.

Long live democracy—freedom and liberty for all!

Kind regards
Felix Lechner

Re: Renaming the FTP Masters

[Roberto C . Sánchez]

On Wed, Nov 10, 2021 at 05:37:55PM -0500, Daniel Kahn Gillmor wrote:
> 
> PS For people who are concerned that a retreat from the term "master" is
>somehow the language police run dangerously amok, it's worth asking
>why you feel so committed to the term "master" that you would fight
>to keep the project we all work on using terminology we all can
>acknowledge is confused and outdated.  If someone is excited to
>improve the project, even if you don't have the capacity to help them
>do it, at least *let* them do it!

Two things:

1/ The assertion "we all can acknowledge is confused and outdated" is
   far fom the case.  This and other discussions on the matter are
   strong evidence that "we can all acknowledge" is a
   mischaracterization.

2/ Claimed improvements must in fact improve things.  Those proposing
   improvements must also demonstrate how the claimed improvements
   provide greater benefit than the cost incurred in implementing the
   improvements.  Your statement seems to imply that those who dissent
   should just be quiet and allow those who want to implement change to
   implement change without any resistance.  I've never ever seen such
   an arrangement actually result in a good outcome.  

The "FTP Masters" rename primarily concerns the team itself, but it has
the potential to affect every member of the project.  Personally, I
rather value the opinions and ideas of those affected and think that
those should be considered alongside the proposals for change.  That's
the way this project has determined that we should do things.  If we as
a project allow some to make changes without considering the concerns of
those affected by the changes, we are not being faithful to our own
principles.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Renaming the FTP Masters

[Gard Spreemann]

Daniel Kahn Gillmor  writes:

> PS For people who are concerned that a retreat from the term "master" is
>somehow the language police run dangerously amok, it's worth asking
>why you feel so committed to the term "master" that you would fight
>to keep the project we all work on using terminology we all can
>acknowledge is confused and outdated.  If someone is excited to
>improve the project, even if you don't have the capacity to help them
>do it, at least *let* them do it!

As someone who did jump into the debate about the term "master", and
regrets doing so (due to contributing irrelevant noise), I wanna say:
Thanks for making this point, you are absolutely right!

 -- Gard


signature.asc
Description: PGP signature

Re: Renaming the FTP Masters

[Jonas Meurer]

Daniel Kahn Gillmor wrote:

On Sat 2021-11-06 11:32:35 +0100, Martin Steigerwald wrote:

Pierre-Elliott Bécue - 06.11.21, 11:06:58 CET:

That being said, the name is indeed outdated, and "Debian Archive
Team" sounds quite nice.


Agreed. I like this name.


Yes, please.  "Debian Archive Team" is fine.  This is fair amount of
work, but it will help make debian not seem quite as archaic as I'm sure
it seems to new prospective users or developers.  Thus it is valuable
work.  But a GR does not seem necessary.


Thank you dkg for writing this mail. Full acknowledgement.

Cheers
 jonas


The way to do this is to consult with the people already on the team and
the DPL.  Select a new name, figure out what work needs to be done
to make the change.  Make a plan, have someone to drive it, and
persist.  It will probably take at least a full debian release cycle.
Changing names is hard, even if you don't have reactionary pushback.

Many things might be touched by this: e-mail addresses; mailing lists;
text in debian policy or the developer's reference; DNS labels; OpenPGP
certificates; SSH host information; wiki entries; software like dupload;
etc (fortunately, the archaic team name doesn't appear in the
Constitution or the DFSG).

Consider upgrade paths and how to deprecate the old name safely: when
updating e-mail addresses, can you create an alias from the old label to
the new address?  How about DNS records?  How should we handle mailing
list archives?  When/how should you send a deprecation warning when
people use the old label?

Have a timeline that acknowledges the work involved, and plans when to
take each step.  For example, changing DNS records, e-mail addresses,
and cryptographic associations will probably be slower/more cumbersome
than changing human-readable labels.  Be prepared to revise the workplan
when someone discovers some other place that the old name is embedded.

You need to find someone or someone(s) who have the capacity and the
skills to actually carry out the right work -- or who at least can keep
track of the work and encourage/support the folks who have the
permissions to do it to get it done.

No one should object to this work if it's done with this kind of
thoughtfulness, care, and attention to detail.

Helping the project through this transition would be a great
contribution to Debian, because it fixes a silly stumbling block that
existing developers have already learned how to ignore, but that does
actually hold the project back from welcoming new members who might have
never heard of FTP (or of using the term "master" to mean administrator
for a machine) before.

This work is *not* the kind of contribution that maps cleanly to a
facility at packaging free software for redistribution.  This is a great
example of why we need more than just package-maintainers as debian
developers.  There are probably many other parts of the project that
need this kind of attention and effort, and we should absolutely *not*
scare people off who want to help fix things.

But let's not make it harder to fix than it already needs to be by
dragging a GR into the mix as well.

   --dkg

PS For people who are concerned that a retreat from the term "master" is
somehow the language police run dangerously amok, it's worth asking
why you feel so committed to the term "master" that you would fight
to keep the project we all work on using terminology we all can
acknowledge is confused and outdated.  If someone is excited to
improve the project, even if you don't have the capacity to help them
do it, at least *let* them do it!