How are the defaults chosen?

How are the defaults chosen?

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Dear all,

In line with the recent and current discussions on possible changes
to the defaults, I have come to realize that I don't know what the
reasons for choosing the current defaults is, in many cases.

For example, in some cases, the option which is deemed superior,
even though it can be more confusing, is the default: undo-ring vs
undo-only/undo-only-redo.

In some cases, it is the opposite, the superior option is left for the
user to activate, the default behaviour is the simple one: list-buffers
vs ibuffer, all the commands marked 'disabled.

In some cases, where there is no clear superior/confusing, the
default option is the one you would find in most other software:
delete-selection-mode.

And yet, in others, it is not the case: visual-line-mode is not enabled
by default.

I'm not trying to start a new discussion on each one of those defaults,
but are there clear guidelines on what makes a default value better
than another?

Or is it just a dozen individual discussions, sometimes resulting in
a new default, and in all other cases the default is whichever option
appeared first?

If the latter, maybe spending time to agree on or decree such guidelines,
at the same time as on how to change the defaults in the least
disruptive way possible (already in progress) would help both with
the current and the inevitable future discussions?

Thibaut

[-- Attachment #2: Type: text/html, Size: 1857 bytes --]

Re: How are the defaults chosen?

[Vasilij Schneidermann]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

> I'm not trying to start a new discussion on each one of those defaults,
> but are there clear guidelines on what makes a default value better
> than another?

I'm afraid that's just wishful thinking.  Personally, I try thinking hard about
a reasonable default and avoid changing anything after that so that no user has
to worry about unreasonable breakage after updating.

> Or is it just a dozen individual discussions, sometimes resulting in
> a new default, and in all other cases the default is whichever option
> appeared first?

This sounds more like it.  Given that backwards-compatibility is such a big
deal, whatever setting appeared first is bound to set a precedent.  It requires
big activation energy to actively change that default.  Bonus: There is bound
to be less users using a non-default setting compared to those using the
default one, so even comparing user experience reports to judge the benefits of
changing the default is going to be challenging (not even accounting for
phenomena such as the silent majority of happy users or vocal minorities).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: How are the defaults chosen?

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Wed, 9 Sep 2020 10:02:15 +0200
> 
> I'm not trying to start a new discussion on each one of those defaults, 
> but are there clear guidelines on what makes a default value better 
> than another? 

No, no guidelines, just a lot of common sense and some discussions
here and there.

> Or is it just a dozen individual discussions, sometimes resulting in 
> a new default, and in all other cases the default is whichever option 
> appeared first?

Yes.

> If the latter, maybe spending time to agree on or decree such guidelines, 
> at the same time as on how to change the defaults in the least 
> disruptive way possible (already in progress) would help both with
> the current and the inevitable future discussions?

How probable is the success of such a discussion, do you think?  We
cannot even agree on specific options, and here you suggest to take
this disagreement to a much higher and abstract level.

Re: How are the defaults chosen?

[Göktuğ Kayaalp]

On 2020-09-09 17:25 +03, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Thibaut Verron <thibaut.verron@gmail.com>
>> Date: Wed, 9 Sep 2020 10:02:15 +0200
>> If the latter, maybe spending time to agree on or decree such guidelines,
>> at the same time as on how to change the defaults in the least
>> disruptive way possible (already in progress) would help both with
>> the current and the inevitable future discussions?
>
> How probable is the success of such a discussion, do you think?  We
> cannot even agree on specific options, and here you suggest to take
> this disagreement to a much higher and abstract level.

I’m no expert on large long standing projects (or small projects that
die quickly, for that matter), but I’d risk the generalisation that most
defaults boil down to historical accident.

I doubt we can come up with any useful guidelines or rules to make it
into a more ‘objective’ process that could apply generally, but maybe
it’d be a nice idea to have the rough rule of thumb that ‘defaults of
user-facing variables, or whether some modes are enabled by default,
should be debated before new features are merged’.  That possibly
already is how stuff happens, but we could just emphasise it as a
conscious UX decision that’ll need to be supported once released.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: How are the defaults chosen?

[Stefan Kangas]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> I doubt we can come up with any useful guidelines or rules to make it
> into a more ‘objective’ process that could apply generally, but maybe
> it’d be a nice idea to have the rough rule of thumb that ‘defaults of
> user-facing variables, or whether some modes are enabled by default,
> should be debated before new features are merged’.  That possibly
> already is how stuff happens, but we could just emphasise it as a
> conscious UX decision that’ll need to be supported once released.

Yes, that is what already happens.  No need for red tape.

This entire discussion seems to start out from the premise that the
defaults change willy-nilly, when the reality is that Emacs is famous
precisely for being very backwards compatible and conservative.  They
change only when there are strong reasons to do so.

I think it would be more useful to demonstrate some important breaking
changes that we should not have done.  Then we could draw the necessary
lessons from that to avoid such a situation in the future.

For example, perhaps those breaking changes were just bugs or mistakes,
just like the breaking changes that happen in any software project (yes,
including the Linux kernel).  One way to improve that is to write more
unit tests.  Everyone is free to help with that work.

Re: How are the defaults chosen?

[Göktuğ Kayaalp]

On 2020-09-09 18:07 +03, Stefan Kangas <stefankangas@gmail.com> wrote:
> This entire discussion seems to start out from the premise that the
> defaults change willy-nilly, when the reality is that Emacs is famous
> precisely for being very backwards compatible and conservative.  They
> change only when there are strong reasons to do so.

I think this discussion is happening because until recently Emacs was
the kind of software where the users were the developers and the
developers were the users.  Even if a user weren’t actively
participating here, they were aware of it and how things happened.  But
recently we’re experiencing an influx of new users that are coming from
different background and through different pathways who are not really
familiar with how things happen, and clear explanations of how things
happen here could help bridge the gap.

> I think it would be more useful to demonstrate some important breaking
> changes that we should not have done.

Didn’t intend to imply such stuff happened.  Sorry if it was understood
that way.  Just that, as above, there’s a large community of Emacsers
that are not familiar with say pre-2010 FOSS development, with how
things are decided in a mailing list, debbugs, etc.


--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: How are the defaults chosen?

[Stefan Kangas]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> Just that, as above, there’s a large community of Emacsers that are
> not familiar with say pre-2010 FOSS development, with how things are
> decided in a mailing list, debbugs, etc.

Agreed.

AFAIK, we are looking for volunteers to help with finding a satisfactory
alternative to debbugs.  The biggest challenge seems to be to
transparently support both a web based and an email based
workflow.  Existing solutions usually do either one or the other well,
but not both.  There was a thread here about this in the last year.

This would require some work, but the benefits could be significant for
the project as a whole.

Re: How are the defaults chosen?

[Göktuğ Kayaalp]

On 2020-09-09 19:27 +03, Stefan Kangas <stefankangas@gmail.com> wrote:
> AFAIK, we are looking for volunteers to help with finding a satisfactory
> alternative to debbugs.  The biggest challenge seems to be to
> transparently support both a web based and an email based
> workflow.  Existing solutions usually do either one or the other well,
> but not both.  There was a thread here about this in the last year.

Having zero expertise I’d refrain from volunteering but the software of
Sourcehut <https://sr.ht> could maybe of use?



-- 
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: How are the defaults chosen?

[Bonface M. K.]

[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> On 2020-09-09 18:07 +03, Stefan Kangas <stefankangas@gmail.com> wrote:
>> This entire discussion seems to start out from the premise that the
>> defaults change willy-nilly, when the reality is that Emacs is famous
>> precisely for being very backwards compatible and conservative.  They
>> change only when there are strong reasons to do so.
>
> I think this discussion is happening because until recently Emacs was
> the kind of software where the users were the developers and the
> developers were the users.  Even if a user weren’t actively
> participating here, they were aware of it and how things happened.  But
> recently we’re experiencing an influx of new users that are coming from
> different background and through different pathways who are not really
> familiar with how things happen, and clear explanations of how things
> happen here could help bridge the gap.
>
>> I think it would be more useful to demonstrate some important breaking
>> changes that we should not have done.
>
> Didn’t intend to imply such stuff happened.  Sorry if it was understood
> that way.  Just that, as above, there’s a large community of Emacsers
> that are not familiar with say pre-2010 FOSS development, with how
> things are decided in a mailing list, debbugs, etc.
>

I'm exactly this user(Also first time posting here). I stumbled into
emacs by accident(I looked up "opposite of vim" online and found Emacs
and I've been using it ever since). Started using debbugs recently
because of the GUIX and Guile projects(that space has a lot of Emacses
users that occasionally give tips).

>
> --
> İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
> pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427
>
>

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
One Divine Emacs To Rule Them All
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 869 bytes --]

Re: How are the defaults chosen?

[Daniel Martín]

Göktuğ Kayaalp <self@gkayaalp.com> writes:
>
> Having zero expertise I’d refrain from volunteering but the software of
> Sourcehut <https://sr.ht> could maybe of use?

SourceHut is still in an early development stage, but seems like a good
implementation of the now popular GitHub/Gitlab development workflow on
top of mailing lists. It may definitely lower the barrier to contribute
code to Emacs, or to report a problem.

I see some SourceHut features could benefit Emacs development in other
aspects as well, like the CI integration it offers.

It's also free software, so it would be ethical to use it.

Re: How are the defaults chosen?

[Ergus]

On Thu, Sep 10, 2020 at 01:06:18AM +0200, Daniel Mart??n wrote:
>G??ktu?? Kayaalp <self@gkayaalp.com> writes:
>>
>> Having zero expertise I???d refrain from volunteering but the software of
>> Sourcehut <https://sr.ht> could maybe of use?
>
>SourceHut is still in an early development stage, but seems like a good
>implementation of the now popular GitHub/Gitlab development workflow on
>top of mailing lists. It may definitely lower the barrier to contribute
>code to Emacs, or to report a problem.
>
>I see some SourceHut features could benefit Emacs development in other
>aspects as well, like the CI integration it offers.
>
>It's also free software, so it would be ethical to use it.
>
Actually not too much time ago there was a thread about migrating to the
self-managed version of gitlab.

https://about.gitlab.com/install/

This is what we use in my work and it is pretty completed and
functional. AFAIK it is open source:

https://gitlab.com/gitlab-org/gitlab

And it works pretty fine out of the box with minimal configuration. The
common integration with grafana, jenkins works pretty fine (I use it
every day in my work) and the developer community is very open, so if
there is any specific feature we need and it is not available they are
usually available to help.

AFAIR the only missing problem was the integration with emacs to track
issues, and other "advanced" functionalities from there. But so far
there were some initial work already done like:

https://github.com/nlamirault/emacs-gitlab
https://gitlab.com/joewreschnig/gitlab-ci-mode/
https://github.com/nlamirault/emacs-gitlab

I think that SourceHut will have the same limitations and will be less
stable than gitlab at the moment.

Re: How are the defaults chosen?

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> Actually not too much time ago there was a thread about migrating to the
> self-managed version of gitlab.

The identified issues with GitLab are tracked here:

https://gitlab.com/gitlab-org/gitlab/-/issues/28152

> I think that SourceHut will have the same limitations and will be less
> stable than gitlab at the moment.

AFAIU, SourceHut has the explicit goal of enabling email based
workflows, which does sound in line with our needs.  But it is still
explicitly in alpha.

Re: How are the defaults chosen?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

To understand the defaults, you need to keep in mind the history, both
that of implementing various features, and that of key bindings.

It is easy to add a feature, much harder to change the default.

It is easy to add a command, hard to find a short key binding for it.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How are the defaults chosen?

[Theodor Thornhill]

>
>AFAIU, SourceHut has the explicit goal of enabling email based
>workflows, which does sound in line with our needs.  But it is still
>explicitly in alpha.
>

Sourcehut is nearing beta stage, I think. Pinging Drew, maybe he can offer some insights :)

Theodor Thornhill

Re: How are the defaults chosen?

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

>
> How probable is the success of such a discussion, do you think?  We
> cannot even agree on specific options, and here you suggest to take
> this disagreement to a much higher and abstract level.
>

That's a good point. If "success" means "agreement on a single guideline",
I think it is 0.
But I'd say that "agreement that everybody wants A, B or C as main
guidelines" (and may
still disagree on how to achieve them) would still be progress.

I think that the "higher level discussion" could also be less emotional and
less multi-directional,
by not looking at specific options. I was surprised to see in the other
discussion some messages
arguing that ibuffer is too confusing compared to list-buffers, and others
arguing that undo/redo
is inferior to the undo-ring model to the point of being unusable.

If anything, thinking about such guidelines should give indications as to
what the "themes"
should be. I imagine that everybody has an internal model of what a
barebones emacs should
be (e.g. actually barebones, or simplified settings, or superior paradigms
in full...), and while
there are certainly thousands of combinations of options to realize those
models, there can't be
that many models.

In that sense, agreeing on a subset of goals might be an easier task than
agreeing on a set
of options.

But that might indeed be wishful thinking, and I didn't realize at the time
of posting that it makes
the discussion essentially a duplicate of the one on themes. Sorry about
that.

Thibaut

[-- Attachment #2: Type: text/html, Size: 2069 bytes --]

Re: How are the defaults chosen?

[Drew DeVault]

Do you have more context? I don't know what this is.

Re: How are the defaults chosen?

[Theodor Thornhill]

> Do you have more context? I don't know what this is.

Sure - I'll quote some stuff from earlier.  The discussion is around how
to modernize the process around contributing to emacs.  It seems like
some of the arguments made here are the same you seem to want to tackle
with SourceHut. I am sure you are not aware, but different forges have
been evaluated:
https://www.gnu.org/software/repo-criteria-evaluation.html

The whole discussion that prompted me to ping you starts here:
https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00386.html

See some selected quotes below:

Stefan Kangas mentions: 
> AFAIK, we are looking for volunteers to help with finding a satisfactory
> alternative to debbugs.  The biggest challenge seems to be to
> transparently support both a web based and an email based
> workflow.  Existing solutions usually do either one or the other well,
> but not both.  There was a thread here about this in the last year.


Later, sourcehut is mentioned:

>> Göktuğ Kayaalp <self@gkayaalp.com> writes:
>> Having zero expertise I’d refrain from volunteering but the software of
>> Sourcehut <https://sr.ht> could maybe of use?
>
> SourceHut is still in an early development stage, but seems like a good
> implementation of the now popular GitHub/Gitlab development workflow on
> top of mailing lists. It may definitely lower the barrier to contribute
> code to Emacs, or to report a problem.

And this is where I though you could chime in a bit more, rather than us
just having opinions :)

> Stefan Kangas writes
> AFAIU, SourceHut has the explicit goal of enabling email based
> workflows, which does sound in line with our needs.  But it is still
> explicitly in alpha.


All the best,
Theodor Thornhill

Re: How are the defaults chosen?

[Drew DeVault]

On Thu Sep 10, 2020 at 8:47 AM EDT, Theodor Thornhill wrote:
> Sure - I'll quote some stuff from earlier.

Cheers :)

> The discussion is around how to modernize the process around
> contributing to emacs. It seems like some of the arguments made here
> are the same you seem to want to tackle with SourceHut. I am sure you
> are not aware, but different forges have been evaluated:
> https://www.gnu.org/software/repo-criteria-evaluation.html

I am aware, actually, and I have submitted an evaluation for sourcehut
by these criteria. Unfortunately this page is outdated and unmaintained,
so it didn't go anywhere.

https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CC03B4X6WE7XN.9NAXAORGDJ0B%40homura%3E

There have been a few small improvements since this was written.

> AFAIK, we are looking for volunteers to help with finding a satisfactory
> alternative to debbugs.  The biggest challenge seems to be to
> transparently support both a web based and an email based
> workflow.  Existing solutions usually do either one or the other well,
> but not both.  There was a thread here about this in the last year.

Aye, todo.sr.ht is a good replacement for debbugs. You can submit,
comment on, and manage tickets by email, with or without an account, and
with an account you can do all of those in a web browser as well.

> Stefan Kangas writes
> AFAIU, SourceHut has the explicit goal of enabling email based
> workflows, which does sound in line with our needs.  But it is still
> explicitly in alpha.

For the record, the alpha is not a vague sense of instability or
incompleteness, but rather a specific set of guarantees:

https://sourcehut.org/alpha-details/

Most of this relates to the hosted offering, but the same is true of the
software itself, which can be self-hosted (it's 100% free/libre
software). The software is approaching completion and most of the daily
use features (like email for tickets) are robust and battle tested. The
hosted service is also very reliable, with less downtime than both
GitHub and GitLab this year. Data security is also taken very
seriously-- all data is stored with at least 4x redundancy, and
sometimes more. The performance is also best in class:

https://forgeperf.org

The main limitations of the alpha are:

- Limited integration between services
- The right is reserved to make backwards-incompatible API changes
- Documentation is incomplete
- Payment is optional for the hosted service, and will ultimately become
  mandatory for project owners (but not contributors)

Additionally, a few important features are still under development, but
if what's already there is suitable for your needs, then suitable indeed
you shall find it.

We started major planning towards the beta this month, which will
resolve all of these issues, and mostly serves as a chance to improve
reliability of the hosted service (though, again, it's already the most
reliable offering available today) and pay back any accumulated tech
debt.

Basically, we're aiming for quality, so these milestones are where we
push ourselves well above and beyond the standard set by most projects
in our domain. Today sourcehut is already a pretty compelling option and
a lot of projects are using it seriously as their primary hosting
platform.

Hope that was helpful. Happy to answer any other questions if you want
to know more or need anything clarified.

Re: How are the defaults chosen?

[Ricardo Wurmus]

Stefan Kangas <stefankangas@gmail.com> writes:

> Göktuğ Kayaalp <self@gkayaalp.com> writes:
>
>> Just that, as above, there’s a large community of Emacsers that are
>> not familiar with say pre-2010 FOSS development, with how things are
>> decided in a mailing list, debbugs, etc.
>
> Agreed.
>
> AFAIK, we are looking for volunteers to help with finding a satisfactory
> alternative to debbugs.

For Guix we provide a web interface to Debbugs that also supports
commenting and indexed search, while aiming to look (if you squint
really hard) similar to the Github issue tracker:

    https://issues.guix.gnu.org/

It’s still all Debbugs under the hood (for better or worse).
Code is here: https://git.elephly.net/gitweb.cgi?p=software/mumi.git

-- 
Ricardo

RE: How are the defaults chosen?

[Drew Adams]

> Sourcehut is nearing beta stage, I think. Pinging Drew, maybe he can offer
> some insights :)

(I guess you mean some other Drew than me.
I know nothing about Sourcehut.)

Re: How are the defaults chosen?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > SourceHut is still in an early development stage, but seems like a good
  > implementation of the now popular GitHub/Gitlab development workflow on
  > top of mailing lists. It may definitely lower the barrier to contribute
  > code to Emacs, or to report a problem.

We should not rush to switch to it, but I agree it sounds promising
at this low level of detail.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How are the defaults chosen?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > For Guix we provide a web interface to Debbugs that also supports
  > commenting and indexed search, while aiming to look (if you squint
  > really hard) similar to the Github issue tracker:

      > https://issues.guix.gnu.org/

Does this satisfy (more or less) those of you who are unhappy with
debbugs?  Is this a solution to that issue?  I hope so.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How are the defaults chosen?

[Ricardo Wurmus]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > For Guix we provide a web interface to Debbugs that also supports
>   > commenting and indexed search, while aiming to look (if you squint
>   > really hard) similar to the Github issue tracker:
>
>       > https://issues.guix.gnu.org/
>
> Does this satisfy (more or less) those of you who are unhappy with
> debbugs?  Is this a solution to that issue?  I hope so.

I cannot speak for all those who use this web interface, but I have
heard very positive comments about it over the years.  The “comment via
web interface” feature seems to be in regular use (as far as I can tell
from the logs) and by different people (new contributors as well as old
ones).  I received enough bug reports about the initial implementation
of the search to know that this, too, is used enthusiastically.

What I don’t know is if this is *enough* for those who crave the elusive
“modern”-looking web interface, and would really much rather see us use
Gitlab or Github.  The features that this web interface offers are
obviously different from those of Github and Gitlab, and some are
difficult to provide due to the design of Debbugs.

But overall I think the experiment has been a success.

-- 
Ricardo

Re: How are the defaults chosen?

[Dmitry Gutov]

On 12.09.2020 09:19, Ricardo Wurmus wrote:
> I cannot speak for all those who use this web interface, but I have
> heard very positive comments about it over the years.  The “comment via
> web interface” feature seems to be in regular use (as far as I can tell
> from the logs) and by different people (new contributors as well as old
> ones).  I received enough bug reports about the initial implementation
> of the search to know that this, too, is used enthusiastically.
> 
> What I don’t know is if this is*enough*  for those who crave the elusive
> “modern”-looking web interface, and would really much rather see us use
> Gitlab or Github.  The features that this web interface offers are
> obviously different from those of Github and Gitlab, and some are
> difficult to provide due to the design of Debbugs.

The looks are an improvement, but of course it is not "enough", to any 
meaningful degree, exactly because of the lacking features.

Re: How are the defaults chosen?

[Ricardo Wurmus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 12.09.2020 09:19, Ricardo Wurmus wrote:
>> I cannot speak for all those who use this web interface, but I have
>> heard very positive comments about it over the years.  The “comment via
>> web interface” feature seems to be in regular use (as far as I can tell
>> from the logs) and by different people (new contributors as well as old
>> ones).  I received enough bug reports about the initial implementation
>> of the search to know that this, too, is used enthusiastically.
>> What I don’t know is if this is*enough*  for those who crave the
>> elusive
>> “modern”-looking web interface, and would really much rather see us use
>> Gitlab or Github.  The features that this web interface offers are
>> obviously different from those of Github and Gitlab, and some are
>> difficult to provide due to the design of Debbugs.
>
> The looks are an improvement, but of course it is not "enough", to any
> meaningful degree, exactly because of the lacking features.

I don’t think you’re a user of the Guix bug tracker, so I don’t think
you can claim it’s not enough.  We have observed that the bug tracker
gets a lot more attention (noticeably more interactions from people who
don’t use M-x debbugs-gnu than before), in spite of the fact that
Debbugs *already* has a web interface that many considered unattractive.

“lacking features” is hard to quantify.  For some the only feature they
are interested in is to be able to stay within their Github browser
session.  Obviously we can’t offer that, no matter how hard we try.  But
things like syntax hightlighting, diff colouring, fast indexed search,
tagging, etc — those are things that we can and do provide, and if that
leads to more people interacting with the bug tracker than before, then
I consider it “enough” to a “meaningful degree” considering these
metrics.

-- 
Ricardo

Re: How are the defaults chosen?

[Dmitry Gutov]

On 12.09.2020 15:20, Ricardo Wurmus wrote:
>> The looks are an improvement, but of course it is not "enough", to any
>> meaningful degree, exactly because of the lacking features.
> I don’t think you’re a user of the Guix bug tracker, so I don’t think
> you can claim it’s not enough.

I'm fairly sure the question was asked in the context of potentially 
using it for Emacs development. And I am an Emacs developer.

> We have observed that the bug tracker
> gets a lot more attention (noticeably more interactions from people who
> don’t use M-x debbugs-gnu than before), in spite of the fact that
> Debbugs*already*  has a web interface that many considered unattractive.

I'm sure it's an improvement.

> “lacking features” is hard to quantify.  For some the only feature they
> are interested in is to be able to stay within their Github browser
> session.  Obviously we can’t offer that, no matter how hard we try.

Sure. But if you look back in the mailing list archives, there have been 
several discussions about using GitLab, for example. For its features. 
Being able to stay within one's Github browser session is not one of them.