Re: Using apt-get after Debian installation

[Paul Wise]

On Mon, Apr 13, 2020 at 7:24 PM Nathanael Skrepek wrote:

> I want to offer a suggestion, because i was a little bit puzzled by the 
> following.

Please file a report about this so the installer team can work on fixing it:

https://www.debian.org/releases/stable/amd64/ch05s04#submit-bug

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Draft Delegation for the Community Team

[Steve McIntyre]

Hi Sam,

On Mon, Apr 13, 2020 at 11:19:40AM -0400, Debian Project Leader wrote:
>
>AS I understand it the only open issue preventing a delegation is the
>following; we need to find wording that makes it clear you can write to
>parties other than the CT.
>
>> >> * To respond to concerns raised by members of the project or
>> >> people interacting with them, working with individuals to help
>> >> them.
>> 
>> my intent was that  if you write to the DPL, the DPL responds.
>> If you write to the CT, the CT responds.
>> If you write to both, they cooperate.
>> I agree the above bullet doesn't say that; good catch on your part.
>
>How about:
>
>* To respond to concerns directed to the Community Team, raised by members of 
>the project or
> people interacting with them, working with individuals to help
> them.
>
>I need an ack from at least one member of the CT, a NACK from any member
>of the CT will be blocking, and of course comments from the larger
>community are welcome.
>
>If I get an ACK and no other blocking issues come up, my next step is to
>delegate.

That change looks fine to me, sure.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Re: Discourse usability

[Dominic Hargreaves]

On Mon, Apr 13, 2020 at 04:39:17PM -0400, Sam Hartman wrote:
> Martin, Neil has said that he wants to put his effort into Discourse.
> 
> It sounds like you'd try something else.
> I'll admit to wanting to see an attempt at mailman3 or something like
> that but not having the energy to put into it.
> I wonder if you or some of the people who would like to try something
> else could get together and give it a try?

Well, I'm certainly not promising anything, nor do I know if it's
the right thing, but if alioth-lists sticks around for another few
years I expect it'll end up being mailman3.

Dominic

Re: Testing Discourse for Debian - Moderation concepts

[Andy Smith]

Hello,

On Mon, Apr 13, 2020 at 10:33:25PM +0200, Mathias Behrle wrote:
> * Neil McGovern: " Re: Testing Discourse for Debian - Moderation concepts"
>   (Mon, 13 Apr 2020 19:56:28 +0100):
> > I just want to state, I won't debate any issues around freedom of
> > speech. I believe that these do not apply in this context
> 
> I think, freedom of speech *can be* an issue when you hand over moderation to
> a system and random people that are not explicitely delegated to do those 
> tasks.
> 
> > - especially with Debian being a private entity.
> 
> I tried hard to understand this part of hte sentence, but failed. Could you
> please elaborate?

Not to speak for Neil, but it's generally argued that private
entities cannot censor, because a nation/state can tell you that you
cannot express an opinion using your own resources. By contrast a
private entity like Debian can only tell you that you cannot express
that opinion using *Debian's* resources: Debian can't prevent you
from publishing it independently, So Debian can't, under this line
of argument, censor you. And if you look back at some of the most
vocal critics of Debian recently, they certainly have not been
wanting for ways to express their opinions.

But on the other hand a lot of people have a much looser definition
of censorship which includes "I wanted to say X on site Y, but site
Y's admins said I couldn't."

Cheers,
Andy

Re: Testing Discourse for Debian - Moderation concepts

[Sean Whitton]

Hello,

On Mon 13 Apr 2020 at 10:33PM +02, Mathias Behrle wrote:

> The trust system gives me no trust at all. It is very closely bound to
> participation over the web interface, monitors the reading frequency and time
> spent on reading by users.

It seems this is indeed so.[1][2]  I hope that an official Debian
Discourse instance would find a way to turn this off.

[1]  
https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790
[2]  https://meta.discourse.org/t/discourse-new-user-guide/96331 (item 4)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Sean Whitton]

Hello,

On Mon 13 Apr 2020 at 04:54AM +09, Charles Plessy wrote:

> Le Sat, Apr 11, 2020 at 03:05:12PM -0700, Sean Whitton a écrit :
>>
>> For any technical topic (including DEPs) it is important that we can
>> find old discussions in the future, easily, and without there being too
>> many entrypoints into the search.
>
> Hi Sean,
>
> in my experience of DEP driver and Policy editor, long discussion
> archives, especially when they spread over multiple years, are a barrier
> to contribution.  Not only they are increadibly noisy (think for
> instance of discussion archives in the BTS mostly made of quotes of the
> previous messages), but also they are not even comprehensive (for
> instance when part of the discussion happens on IRC or at Debconf).
>
> In that sense, I would expect structured discussion systems such as
> Discourse to be a potential time saver, and therefore lower the barrier
> for contribution to everybody: those who contribute their point of view,
> and those who summarise them.

I agree that it could be useful to impose more structure on archived
discussions than we can do at present.  From other posts in the thread,
it sounds like it might be possible to do this using some sort of
Discourse API-to-mbox scraper, though this software does not exist yet.

Thinking about Policy in particular, it would seem that bugs divide into
(a) coming up with a proposal which has consensus; and (b) coming up
with Policy text.

(a) would more clearly benefit from having more structure.  It is less
clear that (b) would benefit, and (b) benefits from the posting of diffs
and replying using inline comments.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Sean Whitton]

Hello,

On Mon 13 Apr 2020 at 08:38PM +01, Neil McGovern wrote:

> On Sun, Apr 12, 2020 at 07:39:34PM +0200, Enrico Zini wrote:
>> Does Discourse have some kind of export feature, that one could
>> postprocess to get for example a mailbox of annotated emails?
>>
>
> Yes, though I think there's just automated ways of doing this for the
> entire database, or for your *own* data at the moment. It would be
> fairly trivial to do this yourself though, as Discoruse is primarily two
> things:
> 1) An API
> 2) A webpage that consumes that API.
>
> If you can do it via the web, you can do it via the API.

Great!  Assuming the API is sufficiently stable, we could start
archiving locked/closed threads to monthly mboxes on master.d.o

Do you think that would end up capturing all discussions, with possibly
a few weeks delay?  Is it typical in Discourse use to lock/close threads
after a certain point?  And do you think the API is stable enough for us
to start doing something like this?

Thank you for your input.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Sean Whitton]

Hello,

On Sun 12 Apr 2020 at 07:39PM +02, Enrico Zini wrote:

> Things that the current list discussion doesn't easily give:
>
>  - +1 kind of feedback, or simple agreement, tends to unexpressed:
>people only reply if they have a problem with things, and shut up
>otherwise.
>
>For example, the recent Salsa as OIDC provider discussion had a
>relatively small amount of people contributing: does it mean that a
>lot of people just agree, or does it mean that only few people care?
>
>Silent assent and only negative feedback is a very demotivating
>process to go through putting a proposal up for discussion.

That makes sense.  Thanks.  I do not find "+1" feedback particular
valuable in most contexts, but I understand your explanation for how
it could be valuable and am grateful for it.

>  - Some kind of weighting of posts. Sometimes I wonder: "is it just me,
>or this objection is not that relevant?", and I have no real way to
>know, besides maybe polling my social bubble, which could be biased.
>
>Ranking of perceived importants of topics or aspects discussed might
>have helped me manage the energy I put into the whole discussion,
>going into more detail where I could see there was more interest or
>concern.

Well, I for one trust your judgement as to whether the objection is
relevant :)  But indeed, if you didn't have to spend the time making
that judgement, it would be beneficial.

>> I am concerned that the problem is basically a social one, and so cannot
>> be solved just by using a different software stack to host discussions.
>
> Ish. I think there are may social aspects involved, and the same time
> the process that we currently use has technical or traditional limits
> which filter against various kinds of feedback which people would
> socially be happy to give.
>
> I follow list discussions and some messages make me go "yay! Standing
> ovation!" and some messages I skip after reading part of the first line,
> and some messages make me furious. Socially we might able to express
> that in a way that feeds into the quality and direction of discussions,
> but technically, we currently cannot.

Let me say a bit more.  I tend to think that the bad threads we have are
mainly due to limitations in our communicative skills.  We do not always
succeed in saying what is worth saying in as few words as possible. And,
you can't solve a problem which is due to a lack of human skill by
writing software.

I am open to the possibility that this is not the right perspective to
have.  I have a bias towards assuming that communicative and
informational problems are caused by people not behaving skillfully
enough, when the cause is not otherwise clear.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Discourse usability

[Sam Hartman]

Martin, Neil has said that he wants to put his effort into Discourse.

It sounds like you'd try something else.
I'll admit to wanting to see an attempt at mailman3 or something like
that but not having the energy to put into it.
I wonder if you or some of the people who would like to try something
else could get together and give it a try?

--Sam

Re: Testing Discourse for Debian

[Scott Kitterman]

On Monday, April 13, 2020 3:38:45 PM EDT Neil McGovern wrote:
> On Sun, Apr 12, 2020 at 07:39:34PM +0200, Enrico Zini wrote:
> > Does Discourse have some kind of export feature, that one could
> > postprocess to get for example a mailbox of annotated emails?
> 
> Yes, though I think there's just automated ways of doing this for the
> entire database, or for your *own* data at the moment. It would be
> fairly trivial to do this yourself though, as Discoruse is primarily two
> things:
> 1) An API
> 2) A webpage that consumes that API.
> 
> If you can do it via the web, you can do it via the API.

For me, having an equivalent to lists.debian.org archive is critical.  I 
routinely go there to find posts on lists to which I am not subscribed.  

I've only used discourse a little for upstream Python things and I haven't had 
much luck with understanding the structure of things so I can find them later.

I don't keep my own archives of all the Debian mailing lists and I certainly 
wouldn't do it for something new.

And yes, I'm not in the demographic that's impressed by these shiny new toys.  
I still have yet to figure out any meaningful advantage Slack has over IRC 
despite having worked on projects where I had to use it a lot.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Testing Discourse for Debian - Moderation concepts

[Mathias Behrle]

* Neil McGovern: " Re: Testing Discourse for Debian - Moderation concepts"
  (Mon, 13 Apr 2020 19:56:28 +0100):

> I am going to try and split this out into two replies, so those
> following along can see the different issues. The irony of the
> difficulty on doing this within email may or may not be lost for others.
> 
> On Sun, Apr 12, 2020 at 02:43:31PM -0700, Ihor Antonov wrote:
> > > You have to trust the moderators,   
> > 
> > So far I am not convinced that I can trust you to moderate. 
> >   
> > > and you have to have some mechanism to
> > > evaluate that trust and to discuss it and possibly revoke it if something
> > > goes horribly awry.   
> > 
> > Prevention should always be the first step. Something WILL go wrong but you
> > are too blinded by the immediate sugar candy in front of you.
> >   
> 
> I just want to state, I won't debate any issues around freedom of
> speech. I believe that these do not apply in this context

I think, freedom of speech *can be* an issue when you hand over moderation to
a system and random people that are not explicitely delegated to do those tasks.

> - especially with Debian being a private entity.

I tried hard to understand this part of hte sentence, but failed. Could you
please elaborate?
 
> Now, I do believe you have a comment on moderation, and how this is
> done. This requires me to explain two concepts in Discourse - trust
> levels and flags.
> 
> Firstly, trust levels. These are the levels of "trust" that the platform
> has in any particular user. Instead of explaining it here, please have a
> read of the following:
> https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/
> The short version is that the more a particular account interacts with
> the community in a positive way, the more trust the system has about
> them, and the more privileges they are afforded to assist in
> moderation.

The trust system gives me no trust at all. It is very closely bound to
participation over the web interface, monitors the reading frequency and time
spent on reading by users. Apart from a quite unpleasant feeling of 'big brother
is watching you' I do not see at all a nearly equivalent handling of users who
want to interact over the mail interface. Reading the link above clearly states
for me that mail users are second class citizens in discourse. I completely
fail in understanding someone who states, that discourse has a good email
integration.

> Secondly, flags. Discourse has the opinion that moderation cannot be
> proactive with a small group of users - this doesn't scale. 

It must not scale and it must not be proactive, moderation must be correct and
considerate.

> encourages community members to flag posts. If a post receives
> sufficient flags, it is then automatically hidden. Users may chose to
> "unhide" the post for themseleves if they wish to view it.
> 
> These are then sent to the moderating team to agree, disagree or ignore
> the flag. This will unhide the post, or keep it hidden and offer an
> opportunity for the moderator to suggest the original author edits their
> post in light of the number of flags they got. If an author does so, the
> post automatically unhides.
> 
> All these actions are logged, and affects the trust levels above. In
> fact, every time an admin performs any action on a user, this is
> logged.

Where is it logged? Are the logs public? Where can I see who flagged a post,
took action on it?

> I hope this explains how I believe that moderation is more powerful on
> Discourse, but also more practical, transparent and accountable.

All of the above makes me in contrary believe (together with the experience I
have so far with interaction on discourse, namely discuss.tryton.org), that
discourse is indeed *not* practical, transparent and accountable.

Mathias



-- 

Mathias Behrle ✧ Debian Developer
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Re: Testing Discourse for Debian

[Sean Whitton]

Hello Ihor,

On Sun 12 Apr 2020 at 05:12PM -07, Ihor Antonov wrote:

> I much more like what https://sourcehut.org is doing. They are working on
> improving email workflows without forcing users into web browsers and I think
> this is something we should do to.

It is worth noting that Sourcehut is focusing on using e-mail for purely
technical discussions, such as review of patches by others with the
relevant highly specialised knowledge.

I think Debian is mostly interested in an alternative to mailing lists
for other sorts of discussions, at least at first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Dan Purgert]

On Apr 13, 2020, Russ Allbery wrote:
> Dan Purgert  writes:
> 
> > I think your younger colleagues are perhaps in a similar situation as me
> > then -- the first place they've experienced *real* email volumes is at
> > their first actual professional position; and they don't know how to
> > cope with *everything* being placed into their inbox. I mean, I can't
> > think of any other time before "work" wherein I was getting more than a
> > handful of "important[1]" emails per day; and now I'm suddenly in a
> > position where 30 people all have something "important[2]" to send me.
> 
> I have had this conversation with people before about filtering.  The
> valuable counterpoint is "rather than investing time and effort into
> filtering email into buckets and then working out a strategy for when to
> read those buckets, how about instead we adopt a system that discourages
> people from filling my inbox with crap, and instead allows me to find that
> information when I need it rather than broadcasting it to the world just
> in case?"

It's certainly a good question.  In my case, the "different buckets" are
for "different projects", and as such, "different people external to my
employer, who don't have access to our systems ... and shouldn't be
trusted making tickets in any capacity in the first place."

The company has tried it in the past; but it has usually resulted in
more behind-the-scenes work to delete the few thousand incorrectly made
tickets that blow up the monthly metrics and cost more to correct than a
couple more (American/Western European) tier-1 desk people manning the
phones.

Granted, there might be something better on the project side than
"email"; but honestly, with as much trouble as we have getting on
$external_conf_platform (other than the ones that offer dial-in
numbers), I'd honestly rather just stick to the "unmodern" email and
telephone.

> 
> It's rather hard to argue with that.  My current employer uses email so
> little that at least half the time I go more than a day without bothering
> to open my work email.  All the important stuff is in a ticket system, on
> pull requests, or in tech notes that are indexed and searchable.  I
> haven't missed the email at all.

For the teams that use those platforms, they're absolutely wonderful;
and between groups within our company, we use them pretty regularly
(well, I don't - I'm one of the few teams that doesn't use "ticket
bucket" as a definition of "today's work"; but I fully admit and
understand that I am the oddity here).

> 
> I too am very proud of my email filters, but the best email filters are
> the ones that prevent the email from being sent in the first place.

Well, I mean, I'm totally for getting rid of all users too; but then I
wouldn't be getting paid :)

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281


signature.asc
Description: PGP signature

Discourse usability

[Martin]

Hi Neil, hi project,

thanks for putting effort in communication improvements, either on
the social or on the technical level.

I'm a Discourse user on various instances, but I'm not an admin on
any of them. This is my end-user experience:

Good:

- Discussions are usually well structured. It is easy to find start
  and end points.

- Moderation or other means of filtering seem to work. At least,
  signal to noise ratio was always great.

- Search function returns useful results most of the time.

- "Like this post" is a nice, low-barrier form of acknowledgment.

Bad:

- Offline usage and local archive is hard, i.e. re-reading when
  disconnected, hold back a text, e.g. to think it over, is difficult.

- I like to use the console. Discourse does not work with any console
  browser I tried, nor with eww. Reading is possible, login is not.

- Entering any longer text in a web browser is a nuisance. Like many,
  I manually copy and paste between text editor and browser.

- The web interface is too ponderous, too cluttered, too distracting
  for my taste or maybe for my age cohort.

Ugly:

- Badges. "Earned 'First Emoji'", "Earned 'Anniversary'". Is it only
  me? But I feel devalued and belittled by gamification.

Note, that the "bad" points cannot, unfortunately, be mitigated by
using the email interface instead of the web interface, because:

- It does not represent the same content, i.e. some advantages are
  gone, and this leads to an information imbalance between users.

- Discourse email is badly formatted and disrespects any rules one
  expects in a "real" email conversation, such as quoting.

My personal and preliminary résumé is: "Something like Discourse would
be great, but maybe better something else, esp. w/o gamification?"

Sorry, this got longer than I wanted to.

Re: Testing Discourse for Debian - Alternate interactions

[Russ Allbery]

Ihor Antonov  writes:

> I do apologize if I came across offensively in this thread. English is
> not my native language and often I lack communication skills to express
> what I want in a less blunt way. And often re-reading my own emails It
> picture myself as an angry enraged, which is not how it really is :) On
> top of that I tend to get carried away with metaphors, which was aptly
> noted by Russ.

Thank you very much for saying this, and no worries at all here.  I know
all too well how sometimes I run away with a figure of speech in the
middle of writing a message.

I completely understand your reluctance to assume that everyone has
Firefox or Chrome and wants to interact with a web site.  And I also do
appreciate people watching out for overuse of moderation!  I personally
don't think Debian is likely to have that problem, but other organizations
have, and it's always worth being thoughtful about.

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

Re: Testing Discourse for Debian

[Russ Allbery]

Dan Purgert  writes:

> I think your younger colleagues are perhaps in a similar situation as me
> then -- the first place they've experienced *real* email volumes is at
> their first actual professional position; and they don't know how to
> cope with *everything* being placed into their inbox. I mean, I can't
> think of any other time before "work" wherein I was getting more than a
> handful of "important[1]" emails per day; and now I'm suddenly in a
> position where 30 people all have something "important[2]" to send me.

I have had this conversation with people before about filtering.  The
valuable counterpoint is "rather than investing time and effort into
filtering email into buckets and then working out a strategy for when to
read those buckets, how about instead we adopt a system that discourages
people from filling my inbox with crap, and instead allows me to find that
information when I need it rather than broadcasting it to the world just
in case?"

It's rather hard to argue with that.  My current employer uses email so
little that at least half the time I go more than a day without bothering
to open my work email.  All the important stuff is in a ticket system, on
pull requests, or in tech notes that are indexed and searchable.  I
haven't missed the email at all.

I too am very proud of my email filters, but the best email filters are
the ones that prevent the email from being sent in the first place.

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

Re: Testing Discourse for Debian - Alternate interactions

[Ihor Antonov]

On Monday, April 13, 2020 12:20:28 PM PDT Neil McGovern wrote:

> There is a commitment to improve the email integration from at least one
> Discourse employee, who also happens to be a Debian Developer. I but do
> 
> want to emphasise the point I made in my original mail:
> > It should be noted however, that there is not 1:1 feature partiy with
> > email and the web interface, as Discorse does things that can't easily
> > be done with email. For the majority of users though, email
> > interaction should be "good enough".
> 
> Neil

Thanks for following up, Neil.

I do apologize if I came across offensively in this thread. English is not my 
native language and often I lack communication skills to express what I want 
in a less blunt way. And often re-reading my own emails It picture myself as 
an angry enraged, which is not how it really is :) On top of that I tend to 
get carried away with metaphors, which was aptly noted by Russ.

Considering everything said about Discourse it sounds like it might be 
possible to make mailing list and Discourse web interface co-exist 
(technically Mailman server is going to be replaced by Discourse) and it 
indeed may provide more visibility into moderation.

I care about opening web browser less often as I have emails from multiple 
projects in one convenient Kmail inbox, so if this introduction of Discourse  
will not force me to change that I have nothing to object personally.

Although the tendency of everything migrating to browsers with javascripts 
does worry me, but I think this as off-topic for this conversation.

Thanks.

-- 
Ihor Antonov
https://useplaintext.email

Re: Testing Discourse for Debian

[Neil McGovern]

On Sun, Apr 12, 2020 at 07:39:34PM +0200, Enrico Zini wrote:
> Does Discourse have some kind of export feature, that one could
> postprocess to get for example a mailbox of annotated emails?
> 

Yes, though I think there's just automated ways of doing this for the
entire database, or for your *own* data at the moment. It would be
fairly trivial to do this yourself though, as Discoruse is primarily two
things:
1) An API
2) A webpage that consumes that API.

If you can do it via the web, you can do it via the API.

Neil
-- 


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Dan Purgert]

On Apr 13, 2020, Russ Allbery wrote:
> Dan Purgert  writes:
> 
> > Who makes up the "younger" crowd?  sub 30? sub 20? I mean, I personally
> > was in my mid-20s when I first started using Linux (college), and I had
> > otherwise only been introduced to the internet via AOL.
> 
> Sub 30 was what I was thinking of.  I'm only saying there's a bit of a
> statistical tendency, not that this applies to everyone, obviously.  But
> when I look around at the broader development world, the majority of the
> newer projects seem to not use email at all.  Even when they do, it's not
> where the most useful conversation happens.

Ah, guess I'm just old enough to miss that mark (although, I still do
tend to fall into the "younger" part of the Linux crowd).

The thing with the "newer" projects that I've seen (and maybe I'm just a
curmudgeon trapped in a young person's body) is that they come off to me
as the early dotcom "exactly like X, except on the internet!" stuff.  

> 
> Now, in a lot of cases the real conversation happens on GitHub, which
> isn't exactly the same thing as a forum.  But forums seem to play a large
> role in some of the more vibrant communities (Rust, for instance).

Haven't really gone there - I have noticed a lot of forums in regards to
microcontrollers; but I tend to just leech off of them as I can't stand
the whole "5th post on basically the same subject on the first page"
garbage that (beginner) fora tend to cultivate.

> [...]
> Professionally, I can tell you that my younger colleagues tend to hate
> email and far prefer other communication mechanisms, and that's not
> because they're unaware of how email is used.  The most commonly stated
> reason is that email is full of noise and pointless messages that aren't
> worth reading, compared to other approaches.  That's just anecdotes, not
> data, obviously, but it made me curious to understand what I might be
> missing.  (My past experience is that when younger colleagues get excited
> about a new way of doing things, I should pay attention, because there are
> probably things that I'm missing and that I will appreciate if I look into
> them more deeply.)

I think your younger colleagues are perhaps in a similar situation as me
then -- the first place they've experienced *real* email volumes is at
their first actual professional position; and they don't know how to
cope with *everything* being placed into their inbox. I mean, I can't
think of any other time before "work" wherein I was getting more than a
handful of "important[1]" emails per day; and now I'm suddenly in a
position where 30 people all have something "important[2]" to send me.

It took me several years to finally get an organization system in place
that made the volume not so distracting -- and the first indication my
initial scheme wasn't as good as it could be was seeing an older
colleague's inbox hierarchy (granted, I had a leg up on some other young
people in that I had already been involved with mailing lists in the
past -- my solution just wasn't as refined as it could have been,
because, well work is outlook, and I was a thunderbird guy, so ... )


[1] As in "I need to do something with this"
[2] As in "Probably not directly for me, but I should have a passing
familiarity in case bossman asks"

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281


signature.asc
Description: PGP signature

Using apt-get after Debian installation

[Nathanael Skrepek]

Hello!

I want to offer a suggestion, because i was a little bit puzzled by the 
following.
After the installation of Debian I wanted to install `texlive` by typing 
`apt-get texlive-full` in the terminal (i think the actual packages doesn't 
really matter but anyway), but then there came the message

Media change: please insert the disc labeled
 'Debian GNU/Linux 10.3.0 _Buster_ - Official amd64 DVD Binary-1 
20200208-12:08' in the drive 'media/cdrom' and press [Enter]

However, I used an USB stick to install Debian and plugging in the usb stick 
didn't help. I could find a solution on the internet, which told me to change 
the file `/etc/apt/sources.list` and comment the corresponding line.

I think this should be changed, because it is very confusing and not obvious 
how to continue. At least there should be a dialog that offers the option to 
not use the installation DVD.

Best regards
Nathanael Skrepek

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Peter" == Peter Palfrader  writes:

Peter> On Mon, 13 Apr 2020, Sam Hartman wrote:
>> > "Luca" == Luca Filipozzi  writes:
>> 
Luca> This is why having a central approach to account creation,
Luca> rather than distributed, is worth considering. I'm in favour
Luca> of usernames not changing because one's role changes but that
Luca> does not mean I'm favour of divergent namespaces.
>> 
>> I don't think anyone here is in favor of divergent namespaces.  I
>> think a lot of us think it would be reasonable if salsa became
>> the place at which names were reserved

Peter> Except it's a huge, intensely integrated code-base that
Peter> currently is very hip.  Just like alioth was a few years ago.
Peter> Small is beautiful.

I'm sorry, I don't understand your point at all.
Right now, we are quite dependent on salsa.
Checking salsa for whether a name is reserved  and reserving that name
if it is not is an operation that can be abstractly contained.

Yes, that means if we move away from salsa we either need to:

1) provide a new implementation of that conceptual interface.  If nm and
DSA are the only consumers of the interface, the details can entirely
change, but the idea that we'll need to be able to check namespace
availability and reserve a name  will remain

or

2) At that point accept some level of namespace divergence.  There are
lots of ways of doing this, but I doubt we'd pick option two so I'm not
going to focus on it.

Yes, absolutely, salsa is big.
But abstractions are great because they allow us to isolate one part of
a system from another; they can isolate DSA and NM from various aspects
of salsa's bigness.

Yes, various parts of the project are saying that they want to have
usernames stay consistent enough that they are willing to accept the
technical debt of some interface going forward for figuring out if a
name is reserved and reserving that name.
And that today salsa seems like a good place to put the implementation
of that interface.
That's very very very different than getting stuck with salsa's bigness
on an ongoing basis.

--Sam

Re: Testing Discourse for Debian - Alternate interactions

[Neil McGovern]

I am going to try and split this out into two replies, so those
following along can see the different issues. The irony of the
difficulty on doing this within email may or may not be lost for others.

On Sun, Apr 12, 2020 at 02:43:31PM -0700, Ihor Antonov wrote:
> - There are only 2 browsers out there in existence (Firefox and Chrome
> variants) and duopoly in browser market is already alarming enough.
> There are much more email clients available.
> 

I have tried Epiphany, which works fine for reading and replying.
I have tried with dillo and lynx, which work fine without Javascript
enabled at all for reading.

You can also interact with Discourse via email.

> 2. I can't now use email the way I did. Discord's email interface is
> subpar in spite of what sales people tell you. So If I want "a
> first-class citizen" experience I am stuck with option 1 
> 

This is correct. Discourse interaction by email can never be as good as
interacting with it via a fully featured web browser. This is because,
well, email isn't a fully featured web browser.

There is a commitment to improve the email integration from at least one
Discourse employee, who also happens to be a Debian Developer. I but do
want to emphasise the point I made in my original mail:
> It should be noted however, that there is not 1:1 feature partiy with
> email and the web interface, as Discorse does things that can't easily
> be done with email. For the majority of users though, email
> interaction should be "good enough".

Neil

Re: Testing Discourse for Debian

[Steve McIntyre]

On Mon, Apr 13, 2020 at 10:51:21AM -0700, Russ Allbery wrote:
>
>Sub 30 was what I was thinking of.  I'm only saying there's a bit of a
>statistical tendency, not that this applies to everyone, obviously.  But
>when I look around at the broader development world, the majority of the
>newer projects seem to not use email at all.  Even when they do, it's not
>where the most useful conversation happens.
>
>Now, in a lot of cases the real conversation happens on GitHub, which
>isn't exactly the same thing as a forum.  But forums seem to play a large
>role in some of the more vibrant communities (Rust, for instance).

There was a good talk about this topic at FOSDEM this year:

  https://fosdem.org/2020/schedule/event/nextgencontributors/

>> There is something to be said for educating "younger people" with the
>> old ways -- I mean how many of these "Modern" things are just
>> re-implementations of what previously existed (except with centralized
>> control and "oh yeah, pay us").
>
>This may be the case, but I think those of us who are familiar with email
>have a bit of a tendency (I'm *definitely* including myself in this) to
>jump straight to "let me explain to you how email already does everything
>you want if you just use it properly" without bothering to ask people what
>features they like and really listen to them.
>
>Professionally, I can tell you that my younger colleagues tend to hate
>email and far prefer other communication mechanisms, and that's not
>because they're unaware of how email is used.  The most commonly stated
>reason is that email is full of noise and pointless messages that aren't
>worth reading, compared to other approaches.  That's just anecdotes, not
>data, obviously, but it made me curious to understand what I might be
>missing.  (My past experience is that when younger colleagues get excited
>about a new way of doing things, I should pay attention, because there are
>probably things that I'm missing and that I will appreciate if I look into
>them more deeply.)

Nod. Much as we're comfortable and happy with email, it's important to
keep open-minded and be ready to evaluate other things too. Just
because we happen to like it now, that doesn't mean it's guaranteed to
be the best possible way to communicate *ever*.

Hell, there's a strong confirmation bias here too - how many
potentially great future developers have we lost at a very early stage
because our email-centric workflow didn't appeal to them initially?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Re: Testing Discourse for Debian - Moderation concepts

[Neil McGovern]

I am going to try and split this out into two replies, so those
following along can see the different issues. The irony of the
difficulty on doing this within email may or may not be lost for others.

On Sun, Apr 12, 2020 at 02:43:31PM -0700, Ihor Antonov wrote:
> > You have to trust the moderators, 
> 
> So far I am not convinced that I can trust you to moderate. 
> 
> > and you have to have some mechanism to
> > evaluate that trust and to discuss it and possibly revoke it if something
> > goes horribly awry. 
> 
> Prevention should always be the first step. Something WILL go wrong but you 
> are
> too blinded by the immediate sugar candy in front of you.
> 

I just want to state, I won't debate any issues around freedom of
speech. I believe that these do not apply in this context - especially
with Debian being a private entity.

Now, I do believe you have a comment on moderation, and how this is
done. This requires me to explain two concepts in Discourse - trust
levels and flags.

Firstly, trust levels. These are the levels of "trust" that the platform
has in any particular user. Instead of explaining it here, please have a
read of the following:
https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/
The short version is that the more a particular account interacts with
the community in a positive way, the more trust the system has about
them, and the more privileges they are afforded to assist in
moderation.

Secondly, flags. Discourse has the opinion that moderation cannot be
proactive with a small group of users - this doesn't scale. Instead, it
encourages community members to flag posts. If a post receives
sufficient flags, it is then automatically hidden. Users may chose to
"unhide" the post for themseleves if they wish to view it.

These are then sent to the moderating team to agree, disagree or ignore
the flag. This will unhide the post, or keep it hidden and offer an
opportunity for the moderator to suggest the original author edits their
post in light of the number of flags they got. If an author does so, the
post automatically unhides.

All these actions are logged, and affects the trust levels above. In
fact, every time an admin performs any action on a user, this is
logged.

I hope this explains how I believe that moderation is more powerful on
Discourse, but also more practical, transparent and accountable.

Neil

Re: Salsa as authentication provider for Debian

[Peter Palfrader]

On Mon, 13 Apr 2020, Sam Hartman wrote:

> > "Luca" == Luca Filipozzi  writes:
> 
> Luca> This is why having a central approach to account creation,
> Luca> rather than distributed, is worth considering. I'm in favour
> Luca> of usernames not changing because one's role changes but that
> Luca> does not mean I'm favour of divergent namespaces.
> 
> I don't think anyone here is in favor of divergent namespaces.  I think
> a lot of us think it would be reasonable if salsa became the place at
> which names were reserved

Except it's a huge, intensely integrated code-base that currently is
very hip.  Just like alioth was a few years ago.  Small is beautiful.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Re: Testing Discourse for Debian

[Neil McGovern]

On Mon, Apr 13, 2020 at 04:54:28AM +0900, Charles Plessy wrote:
> In that sense, I would expect structured discussion systems such as
> Discourse to be a potential time saver, and therefore lower the barrier
> for contribution to everybody: those who contribute their point of view,
> and those who summarise them.
> 

Just on this point, Discourse has an auto-summarise feature. This isn't
meant to replace a human summary creator, but should help with
megathreads and save people time.

For example:
https://meta.discourse.org/t/feedback-on-new-hamburger-and-user-menus/32519
has 231 posts, and an estimated read time of 29 minutes. If you click on
"Summarize this Topic", it drops that down to less than 50 posts.

Neil
-- 


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Russ Allbery]

Dan Purgert  writes:

> Who makes up the "younger" crowd?  sub 30? sub 20? I mean, I personally
> was in my mid-20s when I first started using Linux (college), and I had
> otherwise only been introduced to the internet via AOL.

Sub 30 was what I was thinking of.  I'm only saying there's a bit of a
statistical tendency, not that this applies to everyone, obviously.  But
when I look around at the broader development world, the majority of the
newer projects seem to not use email at all.  Even when they do, it's not
where the most useful conversation happens.

Now, in a lot of cases the real conversation happens on GitHub, which
isn't exactly the same thing as a forum.  But forums seem to play a large
role in some of the more vibrant communities (Rust, for instance).

> There is something to be said for educating "younger people" with the
> old ways -- I mean how many of these "Modern" things are just
> re-implementations of what previously existed (except with centralized
> control and "oh yeah, pay us").

This may be the case, but I think those of us who are familiar with email
have a bit of a tendency (I'm *definitely* including myself in this) to
jump straight to "let me explain to you how email already does everything
you want if you just use it properly" without bothering to ask people what
features they like and really listen to them.

Professionally, I can tell you that my younger colleagues tend to hate
email and far prefer other communication mechanisms, and that's not
because they're unaware of how email is used.  The most commonly stated
reason is that email is full of noise and pointless messages that aren't
worth reading, compared to other approaches.  That's just anecdotes, not
data, obviously, but it made me curious to understand what I might be
missing.  (My past experience is that when younger colleagues get excited
about a new way of doing things, I should pay attention, because there are
probably things that I'm missing and that I will appreciate if I look into
them more deeply.)

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

Re: Salsa as authentication provider for Debian

[Pirate Praveen]

On Mon, Apr 13, 2020 at 6:39 pm, Tollef Fog Heen  wrote:

It's not clear to me why removing the -guest restriction has to happen
for sso.d.o to be using Salsa as an IdP, which seems to be your 
primary
goal?  That's my most immediate concern.  Switching to oauth2/OIDC 
seems

like a good idea, and assuming we can move to another broker somewhere
down the line, I have no problems with that happening.



This was already answered here,

https://lists.debian.org/debian-project/2020/04/msg00031.html

On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?

No.  The guest suffix was meant to avoid collisions with Debian
accounts.  And the tool used to enforce it is unmaintained.

Also the only place that can for sure answer if someone is DD is
nm.debian.org, not Salsa.

Re: Salsa as authentication provider for Debian

[Tollef Fog Heen]

]] Enrico Zini 

> On Sat, Apr 11, 2020 at 09:47:39PM +0200, Tollef Fog Heen wrote:
> 
> > We quite regularly have upstreams getting access for weird architecture
> > failures.  There's no particular reason for those people to have salsa
> > accounts.
> 
> I understand those are temporary accounts. Do those cases need an
> arbitrary name from the LDAP namespace?
> 
> Several places I worked with use a pool of time-limited accounts from a
> guestNNN namespace, for example: that could address your use case
> without overlapping with anything else.

We have guest accounts that have been in use longer than the lifecycle
of some DD accounts, so while it would technically work, it wouldn't be
a particularly nice solution.  (You can of course say that requiring
non-DDs registering on salsa to have a -guest suffix isn't nice either,
something I can agree with.)

> > It does to me, since suddenly we have to care about what's on salsa,
> > something we've never had to care about before.
> 
> As I said in 20200409181701.3qqsn5sqq3xbu...@enricozini.org, no, you
> don't need to care about anything: you keep doing what you want, and we
> deal with it.

I think we in practice will want to do that in order to avoid triggering
bugs in software that assumes that user names are consistent.

> So far, I only received requests to keep the status quo as it is
> indefinitely, and very little in terms of counterprosals actionable now,
> besides theoretical new software solutions to be explored, that would
> address the problems I am having.

In case that was directed at me, rather than the wider world: I'm not
requesting you do one thing or another, I'm pointing out some possible
ramifications.

It's not clear to me why removing the -guest restriction has to happen
for sso.d.o to be using Salsa as an IdP, which seems to be your primary
goal?  That's my most immediate concern.  Switching to oauth2/OIDC seems
like a good idea, and assuming we can move to another broker somewhere
down the line, I have no problems with that happening.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Draft Delegation for the Community Team

[Sam Hartman]

AS I understand it the only open issue preventing a delegation is the
following; we need to find wording that makes it clear you can write to
parties other than the CT.

> >> * To respond to concerns raised by members of the project or
> >> people interacting with them, working with individuals to help
> >> them.
> 
> my intent was that  if you write to the DPL, the DPL responds.
> If you write to the CT, the CT responds.
> If you write to both, they cooperate.
> I agree the above bullet doesn't say that; good catch on your part.

How about:

* To respond to concerns directed to the Community Team, raised by members of 
the project or
 people interacting with them, working with individuals to help
 them.

I need an ack from at least one member of the CT, a NACK from any member
of the CT will be blocking, and of course comments from the larger
community are welcome.

If I get an ACK and no other blocking issues come up, my next step is to
delegate.

Re: Wrapping up the Salsa as OIDC provider proposal

[Ben Hutchings]

On Fri, 2020-04-10 at 20:38 +0200, Enrico Zini wrote:
[...]
> * If we drop the requirement of having "-guest" for non-DD users on
>   Salsa, how can one tell if a user is a DD?
> 
> Waldi has a prototype ready for showing official membership status
> prominently and directly on a user's page, with information synced from
> nm.debian.org.
[...]

This seems to address the only concern I had with your proposal. 
Thanks for all your work on SSO.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.




signature.asc
Description: This is a digitally signed message part

Re: Re: Testing Discourse for Debian

[tomas]

On Mon, Apr 13, 2020 at 09:33:27AM -0400, Dan Purgert wrote:

[...]

> > In-reply-to header of your mail, then ;-D
> 
> Drat, didn't realize that didn't pull in :( ; sorry for the gaffe. 

;-D

> > Brought to you by some dinosaur
> 
> I should be getting off your lawn then, right?

:-)

Had I a lawn, and in less strange times than currently, I'd be glad
to invite you to a glass of wine there.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Luca" == Luca Filipozzi  writes:

Luca> This is why having a central approach to account creation,
Luca> rather than distributed, is worth considering. I'm in favour
Luca> of usernames not changing because one's role changes but that
Luca> does not mean I'm favour of divergent namespaces.

I don't think anyone here is in favor of divergent namespaces.  I think
a lot of us think it would be reasonable if salsa became the place at
which names were reserved, probably at first as a matter of practice,
and eventually as other parts of the project sign on over time, with
appropriate auditing and checking.  The other activities that involve
namespace reservations all seem to have a manual component, removing
security concerns that might exist if there was an automated data feed
from salsa that was automatically imported into other parts of the
namespace.

Other solutions would also be reasonable over time.

Re: Re: Testing Discourse for Debian

[Dan Purgert]

On Apr 13, 2020, to...@tuxteam.de wrote:
> On Mon, Apr 13, 2020 at 08:46:02AM -0400, Dan Purgert wrote:
> > On April 12, 2020, Russ Allbery wrote:
> > > [...]
> > > There is some age correlation with the type of communication mechanism
> > > one is comfortable with [...]
> 
> > Who makes up the "younger" crowd? [...]
> 
> > (Aside, apologies if this is goofy / breaks threading - I had to pull
> > the reply-to out of lists.debian.org)
> 
> At least copy the Message-id from https://lists.debian.org into the
> In-reply-to header of your mail, then ;-D

Drat, didn't realize that didn't pull in :( ; sorry for the gaffe. 

> 
> Brought to you by some dinosaur

I should be getting off your lawn then, right?




-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281


signature.asc
Description: PGP signature

Re: Re: Testing Discourse for Debian

[tomas]

On Mon, Apr 13, 2020 at 08:46:02AM -0400, Dan Purgert wrote:
> On April 12, 2020, Russ Allbery wrote:
> > [...]
> > There is some age correlation with the type of communication mechanism
> > one is comfortable with [...]

> Who makes up the "younger" crowd? [...]

> (Aside, apologies if this is goofy / breaks threading - I had to pull
> the reply-to out of lists.debian.org)

At least copy the Message-id from https://lists.debian.org into the
In-reply-to header of your mail, then ;-D

Brought to you by some dinosaur

Cheers
-- t


signature.asc
Description: Digital signature

Re: Re: Testing Discourse for Debian

[Dan Purgert]

On April 12, 2020, Russ Allbery wrote:
> [...]
> There is some age correlation with the type of communication mechanism
> one is comfortable with, and reason to believe that younger people
> skew towards being more comfortable with forums than with email.

Who makes up the "younger" crowd?  sub 30? sub 20? I mean, I personally
was in my mid-20s when I first started using Linux (college), and I had
otherwise only been introduced to the internet via AOL.

Learning that there was so much more beyond "AOL Keywords" took a while
(and then that there was stuff even older took even longer); but I
eventually stumbled upon things like Usenet and mailing lists -- and I'm
personally finding that, once the rules are ingrained; they are
significantly more comfortable to use than the "Modern(tm)"
alternatives.

There is something to be said for educating "younger people" with the
old ways -- I mean how many of these "Modern" things are just
re-implementations of what previously existed (except with centralized
control and "oh yeah, pay us").

(Aside, apologies if this is goofy / breaks threading - I had to pull
the reply-to out of lists.debian.org)


-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[tomas]

On Mon, Apr 13, 2020 at 06:55:25AM +0100, Marcin Kulisz wrote:

[Gigantic quote elided]

> This is not true, and this email is proof of this

What is "this", and then... what is "this"? And "this"?

One of the nicest things in (nearly lost) mails and usenet
culture is the right quoting style.

If you (as you did) copy the entirety of the message you
are replying to and then say "this" (as you did three
times in that short sentence of yours), your readers are
guaranteed to not understand what you are talking of.

Care to explain?

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Testing Discourse for Debian

[Marcin Kulisz]

On 12 April 2020 22:43:31 BST, Ihor Antonov  wrote:
>On Sunday, April 12, 2020 1:15:23 PM PDT Russ Allbery wrote:
>
>> 1. A database-driven discussion system that supports updates lets you
>go
>>beyond the moderation that you're worried about (rejecting
>messages)
>>and do other forms of moderation that help improve the quality of
>>discussion without removing messages.  Examples include splitting
>>threads that have digressed from the original topic to create more
>>focused discussions, pinning important summaries so that people
>see the
>>current status of the discusison quickly, closing old threads so
>that
>>people properly open a new discussion instead of replying to some
>>resolved discussion with a different problem, and even just
>sorting,
>>classifying, and tagging threads so that people can find the
>>discussions they care about more easily.
>> 
>> 2. You can indicate agreement with a proposal or message without
>adding
>>more words that everyone has to read.  The +1 reply in email is
>clunky
>>and adds a lot of noise.  Often it's useful to be able to get a
>quick
>>count of participants who agree with an idea but don't want to
>write
>>their own extended message about it.
>
>The usability concerns that you outlined are legitimate. And some
>usability perks are 
>indeed nice to have. But the price is too high:
>
>1. I am now limited to Web Browser with JavaScript enabled. On mobile I
>am limited to the 
>browser or centrally owned and developed app.
>
>Here is what is wrong with this:
>
>- You are making a God-like judgement call that everyone must have
>graphical 
>environment running, with a hardware powerful enough to run a browser
>with  
>JavaScript. 

This is not true, and this email is proof of this