issue tracker?

issue tracker?

[Anthony Carrico]

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

Does org-mode have an issue tracker, to keep track of which issues are active, or is it just this mailing list?
-- 
Anthony Carrico

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

Re: issue tracker?

[Nick Dokos]

Anthony Carrico <acarrico@memebeam.org> writes:

> Does org-mode have an issue tracker, to keep track of which issues are active, or is it just this mailing list?

Just this mailing list.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: issue tracker?

[James R Miller]

Doesn’t Gogs have a nice issue tracker functionality?

-- 
  James Miller
  james.ryland.miller@gmail.com

Re: issue tracker?

[tomas]

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

On Mon, May 18, 2020 at 06:13:38PM -0500, James R Miller wrote:
> Doesn’t Gogs have a nice issue tracker functionality?

I looked up Gogs. Needs javascript *and* cookies. Wake me up when
there's a plain, straight service which works without any of them.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: issue tracker?

[James R Miller]

My apologies. I thought Gogs was the repository for org as I that is what is linked from the homepage. 

-- 
  James Miller
  james.ryland.miller@gmail.com

Re: issue tracker?

[James R Miller]

(I also don’t understand the knee jerk response away from cookies / JavaScript). Those are just parts of the modern web... Cookies for state and persistent login and JavaScript for making the web page interactive. 

Are you saying you’d want some sort of REST api instead and the website would just be a view into that?

-- 
  James Miller
  james.ryland.miller@gmail.com

Re: issue tracker?

[tomas]

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

On Tue, May 19, 2020 at 09:05:33AM -0500, James R Miller wrote:
> (I also don’t understand the knee jerk response away from
> cookies / JavaScript).

Mine isn't a knee-jerk reaction. It's worse: it's well thought-out.
Discussing that in detail would be far off-topic for this list,
though.

> Those are just parts of the modern web... Cookies for state and persistent login and JavaScript for making the web page interactive. 

There are many things which are "parts of modern X", for many
values of X, which I dislike. I tend to avoid them.

> Are you saying you’d want some sort of REST api instead and the website would just be a view into that?

All well and fine (as long as it is documented). But falling
back to Plain Old HTML just works too.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: issue tracker?

[Bruce D'Arcus]

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

Regardless, doing issue tracking, discussion, and patch submission on a ML
in 2020 is pretty odd and inefficient.

I would have submitted feedback here 6-12 months earlier than I did if org
had a proper issue tracker.

On Tue, May 19, 2020, 3:35 AM <tomas@tuxteam.de> wrote:

> On Mon, May 18, 2020 at 06:13:38PM -0500, James R Miller wrote:
> > Doesn’t Gogs have a nice issue tracker functionality?
>
> I looked up Gogs. Needs javascript *and* cookies. Wake me up when
> there's a plain, straight service which works without any of them.
>
> Cheers
> -- t
>

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

Re: issue tracker?

[Timothy]

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

My 2c: Having a github-esque pubic issue tracker is good for accessibility — in the sense of ease of access to new-comers.
Personally, this is the first time I've engaged in technical discussions on a mailing list, and needing to use a ML did feel like an extra hurdle.

I wouldn't imagine that a Gogs issue tracker would prevent anyone from using the mailing list, but might encourage more people to get involved.
Is there any reason why we can't have both?

Timothy.
On May 19 2020, at 10:58 pm, Bruce D'Arcus <bdarcus@gmail.com> wrote:
> Regardless, doing issue tracking, discussion, and patch submission on a ML in 2020 is pretty odd and inefficient.
>
> I would have submitted feedback here 6-12 months earlier than I did if org had a proper issue tracker.
> On Tue, May 19, 2020, 3:35 AM <tomas@tuxteam.de (mailto:tomas@tuxteam.de)> wrote:
> > On Mon, May 18, 2020 at 06:13:38PM -0500, James R Miller wrote:
> > > Doesn’t Gogs have a nice issue tracker functionality?
> >
> > I looked up Gogs. Needs javascript *and* cookies. Wake me up when
> > there's a plain, straight service which works without any of them.
> >
> > Cheers
> > -- t
>
>


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

Re: issue tracker?

[Russell Adams]

I can't help but chime in here. Using email for project management, patches,
testing, etc is not difficult or unusual.

In fact, the Linux kernel uses email for this purpose. They have a variety of
reasons which were recently covered in some articles. Clearly their code base
and number of developers is overwhelmingly larger than Org, so we must be doing
something right.

https://lwn.net/Articles/702177/

https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/

My personal opinion is I'd always prefer to use my mail client over some
website. I've personally chosen what I think is the best mail client, where I
can easily sort and read mail from mailing lists. It has a fast interface, easy
to read, and is incredibly consistent (yay Mutt!). I can also rapidly edit (in
Emacs!) my replies. I can send an email in a matter of keystrokes, blindly
typing.

Compare that to most websites where I have to wait forever for all the crap
javascript to load, forfeit my privacy to all the trackers and cookies, and then
manage to figure out how their site works. Once done I'm thrown into a
significantly inferior editor box to try and type or paste information in. From
that point, I can only use their website to manage my submission.

The irony that these websites will often notify me *by email* that something has
occurred.

I clearly don't agree that adding a website somehow makes issue tracking or
patch submission magically easier to manage or submit bug information compared
to email.

If you have feedback, please don't hesitate to just send an email to the list
with your questions or comments. This is easily one of my favorite lists and
very welcoming even to controversial opinions.

On Tue, May 19, 2020 at 10:58:26AM -0400, Bruce D'Arcus wrote:
> Regardless, doing issue tracking, discussion, and patch submission on a ML
> in 2020 is pretty odd and inefficient.
>
> I would have submitted feedback here 6-12 months earlier than I did if org
> had a proper issue tracker.
>
> On Tue, May 19, 2020, 3:35 AM <tomas@tuxteam.de> wrote:
>
> > On Mon, May 18, 2020 at 06:13:38PM -0500, James R Miller wrote:
> > > Doesn’t Gogs have a nice issue tracker functionality?
> >
> > I looked up Gogs. Needs javascript *and* cookies. Wake me up when
> > there's a plain, straight service which works without any of them.
> >
> > Cheers
> > -- t
> >


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: issue tracker?

[Timothy]

If you don't mind me adding 2 more cents :P I don't think that email
should be given up in favour of a web client, or that it isn't better in
many ways.

However, if it were possible to have the best of both worlds, is there a
reason why we'd say no? Just taking a guess here, but I imagine it
should be possible to sync up a public issue tracker to the mailing list.

I may have missed something, or be barking up the wrong tree, but those
are my current thoughts :)

On May 20 2020, at 12:57 am, Russell Adams <RLAdams@adamsinfoserv.com> wrote:

> I can't help but chime in here. Using email for project management, patches,
> testing, etc is not difficult or unusual.
>  
> In fact, the Linux kernel uses email for this purpose. They have a
> variety of
> reasons which were recently covered in some articles. Clearly their
> code base
> and number of developers is overwhelmingly larger than Org, so we must
> be doing
> something right.
>  
> https://lwn.net/Articles/702177/
>  
> https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/
>  
> My personal opinion is I'd always prefer to use my mail client over some
> website. I've personally chosen what I think is the best mail client,
> where I
> can easily sort and read mail from mailing lists. It has a fast
> interface, easy
> to read, and is incredibly consistent (yay Mutt!). I can also rapidly
> edit (in
> Emacs!) my replies. I can send an email in a matter of keystrokes, blindly
> typing.
>  
> Compare that to most websites where I have to wait forever for all the crap
> javascript to load, forfeit my privacy to all the trackers and
> cookies, and then
> manage to figure out how their site works. Once done I'm thrown into a
> significantly inferior editor box to try and type or paste information
> in. From
> that point, I can only use their website to manage my submission.
>  
> The irony that these websites will often notify me *by email* that
> something has
> occurred.
>  
> I clearly don't agree that adding a website somehow makes issue
> tracking or
> patch submission magically easier to manage or submit bug information compared
> to email.
>  
> If you have feedback, please don't hesitate to just send an email to
> the list
> with your questions or comments. This is easily one of my favorite
> lists and
> very welcoming even to controversial opinions.
>  
> On Tue, May 19, 2020 at 10:58:26AM -0400, Bruce D'Arcus wrote:
>> Regardless, doing issue tracking, discussion, and patch submission on
>> a ML
>> in 2020 is pretty odd and inefficient.
>>  
>> I would have submitted feedback here 6-12 months earlier than I did
>> if org
>> had a proper issue tracker.
>>  
>> On Tue, May 19, 2020, 3:35 AM <tomas@tuxteam.de> wrote:
>>  
>> > On Mon, May 18, 2020 at 06:13:38PM -0500, James R Miller wrote:
>> > > Doesn’t Gogs have a nice issue tracker functionality?
>> >
>> > I looked up Gogs. Needs javascript *and* cookies. Wake me up when
>> > there's a plain, straight service which works without any of them.
>> >
>> > Cheers
>> > -- t
>> >
>  
>  
> ------------------------------------------------------------------
> Russell Adams                            RLAdams@AdamsInfoServ.com
>  
> PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/
>  
> Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
>  
>

Re: issue tracker?

[Russell Adams]

On Wed, May 20, 2020 at 01:03:50AM +0800, Timothy wrote:
> If you don't mind me adding 2 more cents :P I don't think that email
> should be given up in favour of a web client, or that it isn't better in
> many ways.
>
> However, if it were possible to have the best of both worlds, is there a
> reason why we'd say no? Just taking a guess here, but I imagine it
> should be possible to sync up a public issue tracker to the mailing list.

I can't object to different viewers of list content. It's archived in many
places already, and perhaps those interfaces could filter for bugs or feature
requests. I think there are potential issues though with trying to add any form
of web submission.

 - Who sets up and maintains this new web interface?

 - Where is it hosted?

 - Does this add additional time and effort for the project maintainers?

 - Does this conflict with or supersede the mailing list, thus causing
   maintainers to have to maintain two parallel environments?

While it may sound easy to add, and I understand you may prefer a web interface,
it's a volunteer run project and email is very low effort, low maintenance, and
universally accessible.

> On May 20 2020, at 12:57 am, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
> > I clearly don't agree that adding a website somehow makes issue
> > tracking or
> > patch submission magically easier to manage or submit bug information compared
> > to email.



------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: issue tracker?

[James R Miller]

So, I definitely agree that using Github / Gitlab does expose you to tracking messes and that is something to shun. I figured a self-hosted Gogs instance (which is already being hosted at https://code.orgmode.org/bzg/org-mode) would fix the "tracking" issue.

I think an actual issue tracker has merit to large projects.

And I don't think simply saying "we've always done it through a ML" or "$FOO project is bigger than us and uses a ML" is good enough. $FOO project may very well increase efficiency, code quality, and/or participation by implementing an issue tracker. 

A project to consider then, might be some sort of system that interfaces with the ML (as well as a simple REST api so that issues could be submitted from inside emacs directly), that creates some sort of org-based issue tracker, and then  ox-html exports to a static web page or pages. 
-- 
  James Miller
  james.ryland.miller@gmail.com

Re: issue tracker?

[Eric Abrahamsen]

"James R Miller" <james.ryland.miller@gmail.com> writes:

> So, I definitely agree that using Github / Gitlab does expose you to
> tracking messes and that is something to shun. I figured a self-hosted
> Gogs instance (which is already being hosted at
> https://code.orgmode.org/bzg/org-mode) would fix the "tracking" issue.
>
> I think an actual issue tracker has merit to large projects.

I've been going around doing proselytizing for sr.ht (sourcehut, aka
"Sir Hat"), which is a forge-like site that is very much in line with
Emacs' principles. No tracking (barely any javascript at all),
everything can be driven via email -- it's pretty nice. Could be a good
solution here.

(Not affiliated, though I do give them money.)

Eric

Re: issue tracker?

[Russell Adams]

On Tue, May 19, 2020 at 01:50:26PM -0500, James R Miller wrote:
> I think an actual issue tracker has merit to large projects.
>
> And I don't think simply saying "we've always done it through a ML" or "$FOO
> project is bigger than us and uses a ML" is good enough. $FOO project may very
> well increase efficiency, code quality, and/or participation by implementing
> an issue tracker.
>
> A project to consider then, might be some sort of system that interfaces with
> the ML (as well as a simple REST api so that issues could be submitted from
> inside emacs directly), that creates some sort of org-based issue tracker, and
> then ox-html exports to a static web page or pages.

My point about duplication of effort stands. Who/how/which solution? Who has to
maintain it, and does that make two places to check while managing bugs/patches?

Please note I'm not a complete luddite, nor have I any real influence in any
decision.

However I'll point out that with limited resources, the onus to sufficiently
justify a major change falls on the person(s) making the recommendation. Change
"just because" or "it's prettier" tend to fall on deaf ears in technical
communities.

I'd argue that code quality is more improved by the proper application of
version control than whether bug reports are web based. This appears to already
be the case.

If email is unmanageable, I'd assert that perhaps the user has a poor quality
mail reader that lacks threading support, and perhaps they should find a better
one.

Is there a problem with submitting issues via the mailing list? Has something
gone unaddressed? Do you have any statistics to show that there is decreased
participation because you have to use email? Is something really inefficient at
the moment? Did you have patches ignored?



------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: issue tracker?

[Trey Ethan Harris]

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

On Tue, May 19, 2020 at 15:49 Russell Adams <RLAdams@adamsinfoserv.com>
wrote:

> Is there a problem with submitting issues via the mailing list? Has
> something
> gone unaddressed? Do you have any statistics to show that there is
> decreased
> participation because you have to use email? Is something really
> inefficient at
> the moment? Did you have patches ignored?


I think you have the null hypothesis backwards here. Do you have any
statistics to show that issues _are not_ dropping through the cracks?
Sending a “ping?” message on a ML is generally considered poor netiquette,
and even if it were expected here, would make many requesters
uncomfortable. That’s one of the fundamental things any tracker does—keeps
statistics on and forces every issue to _some_ resolution, even if it’s
“will not fix” or “on hold”. Things don’t just peter out and get forgotten
like on email threads.

(I have not done the exercise of perusing old email threads to see if I can
find issues being dropped on the floor. But I’ve already found several
apparent existence proofs. Whether they’re common or rare is a question I
can’t answer without doing tedious manual work that is the entire raison
d’être of a tracker.)

I wouldn’t dispute that the Linux kernel ML, for the most part, works. But
the Linux kernel mailing list is a rather different beast than the
potential users of an issue tracker for any other software project I can
imagine—the technical acumen expected of contributors is high, quotidian
back-and-forth user-assistance exchanges with non-contributors are not
tolerated, people are usually expected to offer fixes as working code and
not simply prose bug reports or feature requests (except for critical or
security issues), and patches and pull requests on the mailing list are
dealt with using a distributed version-control system that was
purpose-built for the task (though happens to have worked well enough to
because the most widely-used DVCS period).

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

Re: issue tracker?

[Roland Everaert]

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

Sourcehut seams interesting. Did you know if importing github/gitlab
projects, with issues and merge requests (opened and closed) is supported
at the moment?

I noticed it is in alpha, so I don't expect to see all the features of any
of those forges yet.

Before I forget, Does magit+forge works well with sourcehut, especially the
latter, as the former shouldn't have any problem?


Regards,

Roland.


On Tue, May 19, 2020 at 9:43 PM Eric Abrahamsen <eric@ericabrahamsen.net>
wrote:

> "James R Miller" <james.ryland.miller@gmail.com> writes:
>
> > So, I definitely agree that using Github / Gitlab does expose you to
> > tracking messes and that is something to shun. I figured a self-hosted
> > Gogs instance (which is already being hosted at
> > https://code.orgmode.org/bzg/org-mode) would fix the "tracking" issue.
> >
> > I think an actual issue tracker has merit to large projects.
>
> I've been going around doing proselytizing for sr.ht (sourcehut, aka
> "Sir Hat"), which is a forge-like site that is very much in line with
> Emacs' principles. No tracking (barely any javascript at all),
> everything can be driven via email -- it's pretty nice. Could be a good
> solution here.
>
> (Not affiliated, though I do give them money.)
>
> Eric
>
>

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

Re: issue tracker?

[Diego Zamboni]

Hi all,

Interesting discussion. I have also wondered about this - I have not
yet contributed to the Org codebase, but I have wondered if patches
and bug fixes can sometimes get lost among other discussions.

However, ultimately the best tracking system is the one that works for
the developers and their workflow. A full-featured issue tracking
system is useless if the developers don't have the habit of using it.

So, whatever works for Nicolas and all the other wonderful people who
maintain this amazing piece of software for free, works for me :)

Best,
--Diego



On Tue, May 19, 2020 at 10:18 PM Roland Everaert <reveatwork@gmail.com> wrote:
>
> Sourcehut seams interesting. Did you know if importing github/gitlab projects, with issues and merge requests (opened and closed) is supported at the moment?
>
> I noticed it is in alpha, so I don't expect to see all the features of any of those forges yet.
>
> Before I forget, Does magit+forge works well with sourcehut, especially the latter, as the former shouldn't have any problem?
>
>
> Regards,
>
> Roland.
>
>
> On Tue, May 19, 2020 at 9:43 PM Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>>
>> "James R Miller" <james.ryland.miller@gmail.com> writes:
>>
>> > So, I definitely agree that using Github / Gitlab does expose you to
>> > tracking messes and that is something to shun. I figured a self-hosted
>> > Gogs instance (which is already being hosted at
>> > https://code.orgmode.org/bzg/org-mode) would fix the "tracking" issue.
>> >
>> > I think an actual issue tracker has merit to large projects.
>>
>> I've been going around doing proselytizing for sr.ht (sourcehut, aka
>> "Sir Hat"), which is a forge-like site that is very much in line with
>> Emacs' principles. No tracking (barely any javascript at all),
>> everything can be driven via email -- it's pretty nice. Could be a good
>> solution here.
>>
>> (Not affiliated, though I do give them money.)
>>
>> Eric
>>

Re: issue tracker?

[gyro funch]

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

On 5/19/2020 1:48 PM, Russell Adams wrote:
> On Tue, May 19, 2020 at 01:50:26PM -0500, James R Miller wrote:
>> I think an actual issue tracker has merit to large projects.
>>
>> And I don't think simply saying "we've always done it through a ML" or "$FOO
>> project is bigger than us and uses a ML" is good enough. $FOO project may very
>> well increase efficiency, code quality, and/or participation by implementing
>> an issue tracker.
>>
>> A project to consider then, might be some sort of system that interfaces with
>> the ML (as well as a simple REST api so that issues could be submitted from
>> inside emacs directly), that creates some sort of org-based issue tracker, and
>> then ox-html exports to a static web page or pages.
> 
> My point about duplication of effort stands. Who/how/which solution? Who has to
> maintain it, and does that make two places to check while managing bugs/patches?
> 
> Please note I'm not a complete luddite, nor have I any real influence in any
> decision.
> 
> However I'll point out that with limited resources, the onus to sufficiently
> justify a major change falls on the person(s) making the recommendation. Change
> "just because" or "it's prettier" tend to fall on deaf ears in technical
> communities.
> 
> I'd argue that code quality is more improved by the proper application of
> version control than whether bug reports are web based. This appears to already
> be the case.
> 
> If email is unmanageable, I'd assert that perhaps the user has a poor quality
> mail reader that lacks threading support, and perhaps they should find a better
> one.
> 
> Is there a problem with submitting issues via the mailing list? Has something
> gone unaddressed? Do you have any statistics to show that there is decreased
> participation because you have to use email? Is something really inefficient at
> the moment? Did you have patches ignored?
> 

This idea that the tools used by a potential contributor are inadequate
misses the point. If the intention is to keep a project going, or better
yet increase the number of contributors, tools have to be used that will
be convenient and familiar to those thinking about contributing.

For better or worse, the workflows embodied by Github and Gitlab are
familiar to the current generation of potential contributors upon which
sustaining a project will depend.

Holding up the 'Linux uses email for development and thus any project
doing similar is right' fails to recognize the peculiar nature of the
Linux kernel (and its developers) and neglects the thousands of projects
that have increased their visibility and participation by using tools
such as Github. I agree that Github/Gitlab may not be the best choice
owing to their stance or implementation related to software freedom, but
an honest discussion of alternatives seems prudent.

-gyro

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 1795 bytes --]

Re: issue tracker?

[Eric Abrahamsen]

Roland Everaert <reveatwork@gmail.com> writes:

> Sourcehut seams interesting. Did you know if importing github/gitlab
> projects, with issues and merge requests (opened and closed) is supported
> at the moment?

I did a bit of googling, and couldn't find anything, no. The developer
is very responsive, though, and might be worth contacting him directly.
Though I guess Org doesn't have any existing issues to import (unless
it's from Nicolas' development machine).

> I noticed it is in alpha, so I don't expect to see all the features of any
> of those forges yet.

Here are details on "alpha":

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

One issue is that, while payment isn't currently required, it will be
eventually. Perhaps the developer would be willing to make an exception
for Org, or perhaps we should get what we pay for :)

I guess I wouldn't expect Org to migrate away from gnu.org as a mailing
list host, but the option is there.

> Before I forget, Does magit+forge works well with sourcehut, especially the
> latter, as the former shouldn't have any problem?

Forge notes Sourcehut:

https://magit.vc/manual/forge/Supported-Forges-and-Hosts.html#Supported-Semi_002dForges

The thing is that Sourcehut doesn't really do pull requests, which I
think is the tricky part of any "forge". It really is dead simple, and I
think would be most useful as a mirror of Org's code, and an issue
tracker.

Eric

Re: issue tracker?

[James R Miller]

> This idea that the tools used by a potential contributor are inadequate
> misses the point. If the intention is to keep a project going, or better
> yet increase the number of contributors, tools have to be used that will
> be convenient and familiar to those thinking about contributing.
> 
> For better or worse, the workflows embodied by Github and Gitlab are
> familiar to the current generation of potential contributors upon which
> sustaining a project will depend.
> 
> Holding up the 'Linux uses email for development and thus any project
> doing similar is right' fails to recognize the peculiar nature of the
> Linux kernel (and its developers) and neglects the thousands of projects
> that have increased their visibility and participation by using tools
> such as Github. I agree that Github/Gitlab may not be the best choice
> owing to their stance or implementation related to software freedom, but
> an honest discussion of alternatives seems prudent.

This is the point I am trying to (un-eloquently) make. I'm seeing a bunch of 
younger coders interested in emacs (mostly spacemacs and doom); but, 
they get frustrated with the ancient (to them) dev practices.  I'm not 
advocating any rash decisions; simply, whether the project would benefit
from incorporating some sort of simple issue tracker, so that new 
contributors could readily see open tasks / issues / submit bug reports.

My biggest issue with a ML only approach is that it's not easy to see what's 
an open issue unless you spend a long time searching and reading the ML. 
And I feel that that time could be better spent learning the code base
instead of reading the ML. 

-- 
 James Miller
james.ryland.miller@gmail.com

Re: issue tracker?

[Eric S Fraga]

On Tuesday, 19 May 2020 at 18:57, Russell Adams wrote:
> My personal opinion is I'd always prefer to use my mail client over some
> website. 

+∞!

There are some communities that I would love to participate in but do
not because they use, for instance, discourse which has a horrible email
interface.  And their web interface cannot be used via eww, for
instance.

In any case, strictly speaking, some org issues could be submitted via
Emacs's own bug tracker, at least for the version of org that comes with
Emacs?
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc

Re: issue tracker?

[Detlef Steuer]

Am Wed, 20 May 2020 10:22:56 +0100
schrieb Eric S Fraga <e.fraga@ucl.ac.uk>:

> On Tuesday, 19 May 2020 at 18:57, Russell Adams wrote:
> > My personal opinion is I'd always prefer to use my mail client over
> > some website.   
> 
> +∞!

How to add more now? Same here. Mail is functionally superior to a lot
of modern solutions.

A Bugtracker you do not use on a regular basis often is a horrible time sink.
Plus, most of the time you need just another account for a site you
never wanted an account on. 

Furthermore many of the discussions on this list wouldn't have happend,
if the first post went into a bugtracker. 

I would go as far as saying *this list* is one of the fastest reacting
amd friendliest communities I have been part of. The job Nicolas does is
just awesome.

That leads to the next point: If Nicolas decided *he* would love to work
with a bugtracker, I would not complain and open an account.
As it is now, anything that's not in the best interest of our benevolent
developer, should not even be considered :-)

Just my opinion, of course

Detlef


> 
> There are some communities that I would love to participate in but do
> not because they use, for instance, discourse which has a horrible
> email interface.  And their web interface cannot be used via eww, for
> instance.
> 
> In any case, strictly speaking, some org issues could be submitted via
> Emacs's own bug tracker, at least for the version of org that comes
> with Emacs?

Re: issue tracker?

[Stefan Nobis]

Detlef Steuer <steuer@hsu-hh.de> writes:

> I would go as far as saying *this list* is one of the fastest
> reacting amd friendliest communities I have been part of. The job
> Nicolas does is just awesome.

+1!

-- 
Until the next mail...,
Stefan.

Re: issue tracker?

[Jud Taylor]

I second that.

Nicolas, thank you!

Great product, better vision, high energy!





‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, May 20, 2020 7:12 AM, Stefan Nobis <stefan-ml@snobis.de> wrote:

> Detlef Steuer steuer@hsu-hh.de writes:
>
> > I would go as far as saying this list is one of the fastest
> > reacting amd friendliest communities I have been part of. The job
> > Nicolas does is just awesome.
>
> +1!
>
> ------
>
> Until the next mail...,
> Stefan.

RE: issue tracker?

[gennady.uraltsev]

Hello everyone,

 I have been following the org-mode ML and I have seen the discussion about having a bug tracker. I wanted to offer my 2 cents as a non-developer; barely a power user. Org-mode works incredibly well and I use it on a daily basis. It is true that development is very active. However I might say that saying that no bugs fall through the cracks in the ML is a bit of a confirmation bias. My personal experience was different.

 I actually submitted some bug reports through emacs about some slightly less used parts of org-mode e.g. ob-eshell. The mailing list is moderated (or has anti-spam) so the result was that my mail did not appear AT ALL. I had that issue before, too, but here in IRC I was suggested to wait for several days. The previous time I think the e-mail eventually got through. When I submitted the bug report for ob-eshell it never did. I found a workaround by using shell instead of ob-shell so I never pursued the issue. Probably the bug is still there.

 I am glad that the ML works for the most active developers, and I suppose it works well for the linux kernel since it needs to be centralized and somewhat focused. However org-mode could benefit from more community involvement even of newbies, especially around the parts that are "part of" org-mode but are not that often used and don't receive enough love and attention from the main developers. 

A good bug tracker could also help identify parts that are not used or buggy and that should, maybe, be slated for removal or at least separated in a independent package.

 You see, for a beginner a bug is quite daunting because you never know if it is actually a bug or if it is your own fault for misunderstanding or misconfiguring something. And, honestly, in emacs, it is quite easy for a beginner to misconfigure something.  

All this to say that the ML works great and I picked up great ideas while reading through it in my mailbox (I am subscribed), however it still has a significant "gatekeeper" effect. Please, at least address the issue that some bug reports don't even make it to the list AT ALL.   

I do not want this email to be offensive in any way to anyone. I also realize that what I described may not be representative. I excuse myself in advance if my tone was inappropriate. 

More than anything I still wish to thank everyone for a piece of fantastic software that has helped me out crucially on multiple occasions!



Sincerely, 

Gennady

P.S. I wrote essentially the same e-mail on the IRC channel to be sure that it gets delivered somewhere. 

-----Original Message-----
From: Emacs-orgmode <emacs-orgmode-bounces+gennady.uraltsev=gmail.com@gnu.org> On Behalf Of Jud Taylor
Sent: Wednesday, 20 May, 2020 12:42
To: Stefan Nobis <stefan-ml@snobis.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: issue tracker?

I second that.

Nicolas, thank you!

Great product, better vision, high energy!





‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, May 20, 2020 7:12 AM, Stefan Nobis <stefan-ml@snobis.de> wrote:

> Detlef Steuer steuer@hsu-hh.de writes:
>
> > I would go as far as saying this list is one of the fastest reacting 
> > amd friendliest communities I have been part of. The job Nicolas 
> > does is just awesome.
>
> +1!
>
> ------
>
> Until the next mail...,
> Stefan.

Re: issue tracker?

[Bob Newell]

Aloha everyone,

Sometimes a "lower tech" solution is best, or at least offers
a lot of advantages.

What I see as the advantages of resolving issues through a
mailing list are:

* Minimal barriers to entry. If you have an email client of
  ANY type, you're in. No need for anything more. I think this
  is a very big deal, the merits of which can easily be
  underestimated.

* Distributed data. No one has to be responsible for
  maintaining a central database, keeping it secure and
  updated, etc. (except, of course, for the list server but
  that's a different matter). Changes in policy on the
  bug-tracker host don't matter because there is no host.

* A permanent record maintained and replicated widely.
  Everyone who saves their mail from the list has a copy.

I'm certainly not saying that a formal project-management
style issue tracking system is a bad thing; in many use cases,
it can be quite important. But this is an open-source,
distributed effort, non-commercial endeavor, not beholden to a
specific client (the clients are all of us) and clearly not
for profit. The requirements are not the same.

I can't cite statistics, but I wonder if more gets "lost" on
the mailing list than in a formal bug tracking system, where
things do get buried and may not surface for a long time if
ever.

Another big enabling factor is that (as others have mentioned)
this list is very responsive, very open and welcoming, and
almost always courteous and respectful (rather a big thing on
today's internet).

I've posted various things and gotten various replies and
results. When I've reported problems, they've been addressed,
generally quickly and effectively. When I talk about
nice-to-haves, some get responses and some don't, which is
exactly what I'd expect.

I'm very pleased with the way things are working and would
hate to add another layer of complexity without being sure the
upsides were greater than the downsides.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: issue tracker?

[Anthony Carrico]

On 5/18/20 5:24 PM, Anthony Carrico wrote:
> Does org-mode have an issue tracker, to keep track of which issues are 
> active, or is it just this mailing list?

I'm the OP here. My first post to this list generated a lot of feedback. 
I'm not sure I have an opinion, it was an honest question, but I'd like 
to summarize the replies:

1. The mailing list is a good way, perhaps the best way to manage 
discussion threads, including threads about issues (bugs).

2. There isn't an issue tracker.

I think issue tracking could happen on a mailing list. If you tag an 
issue's subject line with OPEN: or CLOSE:, a bot could mail a summary of 
the OPEN: issues to the list periodically (in theory).

Given that the mailing list holds the issues, it would be nice if you 
could import the mailing list into your client as a lump (maildir/mbox). 
Currently you can only download it chunk by chunk, so it isn't really 
practical for a newcomer to import the whole list to do research a new 
issue before reporting it.

-- 
Anthony Carrico

Re: issue tracker?

[James R Miller]

> I think issue tracking could happen on a mailing list. If you tag an 
> issue's subject line with OPEN: or CLOSE:, a bot could mail a summary of 
> the OPEN: issues to the list periodically (in theory).

Something like that would be nice; the bot could even store such info in an org file that could be exported the html occasionally too. 
-- 
  James Miller
  james.ryland.miller@gmail.com

Re: issue tracker?

[Russell Adams]

On Wed, May 20, 2020 at 10:12:38PM -0500, James R Miller wrote:
> > I think issue tracking could happen on a mailing list. If you tag an
> > issue's subject line with OPEN: or CLOSE:, a bot could mail a summary of
> > the OPEN: issues to the list periodically (in theory).
>
> Something like that would be nice; the bot could even store such info in an
> org file that could be exported the html occasionally too.

I think recommended standardized formats for submissions is a great idea.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: issue tracker?

[Kévin Le Gouguec]

"James R Miller" <james.ryland.miller@gmail.com> writes:

>> I think issue tracking could happen on a mailing list. If you tag an 
>> issue's subject line with OPEN: or CLOSE:, a bot could mail a summary of 
>> the OPEN: issues to the list periodically (in theory).
>
> Something like that would be nice; the bot could even store such info in an org file that could be exported the html occasionally too. 

I think you've just described, in order:

- Debbugs (the issue tracking software),

- bug-gnu-emacs@gnu.org (the mailing list),

- control@debbugs.gnu.org and BUGNUMBER-done@debbugs.gnu.org (the bots
  to contact to tag, close or reopen bugs),

- the debbugs-org function from the debbugs.el package (the current bug
  list formatted in an Org buffer),

- https://debbugs.gnu.org (the current bug list formatted as HTML).

Re: issue tracker?

[Nicolas Goaziou]

Hello,

Detlef Steuer <steuer@hsu-hh.de> writes:

> That leads to the next point: If Nicolas decided *he* would love to work
> with a bugtracker, I would not complain and open an account.
> As it is now, anything that's not in the best interest of our benevolent
> developer, should not even be considered :-)

Thank you for your consideration. However, the question of what bug
tracker to use is the maintainer's, not mine. Besides, just to avoid the
confusion, I'm not a diva ;) If it is obvious that a solution is good
for the project, I wouldn't dare opposing it.

Now, I think I should add a few data points:

- Many bug reports, and patches, are "lost" currently. Of course, they
  are still there, if you dig deep enough in the ML archives. But
  I doubt anyone would do that, so it is more realistic to consider them
  lost.

- As pointed out, Org has a bug tracker : Emacs' Debbugs. See
  <https://debbugs.gnu.org/Emacs.html>. Org users do not send bugs
  through it much. It is possibly a cultural thing. In these
  "package.el" days, people may forget that Org is also bundled with
  Emacs. The manual is not clear about it, too. In particular, this bug
  tracker can be used for any Org version, not necessarily the one
  bundled with Emacs. The good thing is that every bug sent there is
  also sent to our ML.

Now, after the facts, some personal rambling about it:

- I have no opinion on the fact that a bug tracker would bring more life
  to the project. It may be, but it is not obvious either. I'm not
  against it anyway.

- The mailing list is the central place in our project, and any
  discussion should all happen here, so that anyone can get involved. In
  particular, a "mini mailing-list" per bug number is not a good thing,
  if messages are not made public in the ML.

- A bug tracker without first-class support for Emacs—i.e., you can do
  anything from Emacs—is missing the point. Therefore, I agree that an
  email-based bug tracker is particularly suited.

- Debbugs has a nice, modern, front end, too: Mumi
  (<https://git.elephly.net/gitweb.cgi?p=software/mumi.git>). See for
  example <http://issues.guix.gnu.org/>.

- No matter what bug tracker (or lack thereof) is used, Org needs more
  reviewers, i.e., more users with write access to the repository.
  Receiving a ton of bug fixes is a certainly great, but is also
  discouraging when you realize you cannot possibly deal with all of
  them.

- Considering the previous point, I doubt switching to a bug tracker
  today would help handling more bug reports. It will induce more work,
  though. For example, some triage happens currently on the ML: if
  a so-called bug report is clearly a misunderstanding, someone here
  often helps the OP without the developers interfering. This never
  happens in the bug tracker Org has actually.

So, in a nutshell, if Bastien, or a future maintainer, decides that Org
project should seriously be using a bug tracker, I suggest to simply
advertise the current one, and add a Mumi interface somewhere.

As the final words, reviewers are welcome, too…

Regards,

-- 
Nicolas Goaziou

Re: issue tracker?

[Bruce D'Arcus]

On Thu, May 21, 2020 at 4:11 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

...

> - Debbugs has a nice, modern, front end, too: Mumi
>   (<https://git.elephly.net/gitweb.cgi?p=software/mumi.git>). See for
>   example <http://issues.guix.gnu.org/>.

That'd be a nice improvement.

Bruce

Re: issue tracker?

[Anthony Carrico]

On 5/21/20 3:31 AM, Kévin Le Gouguec wrote:
> I think you've just described, in order:
> 
> - Debbugs (the issue tracking software),

Yes, I almost mentioned that Debian uses an email based bug tracker, as
a point of reference. I'm not familiar with the details, but I think it
is header based, which is a big ask for users.

-- 
Anthony Carrico

Re: issue tracker?

[tomas]

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

On Thu, May 21, 2020 at 10:18:27AM -0400, Anthony Carrico wrote:
> On 5/21/20 3:31 AM, Kévin Le Gouguec wrote:
> > I think you've just described, in order:
> > 
> > - Debbugs (the issue tracking software),
> 
> Yes, I almost mentioned that Debian uses an email based bug tracker, as
> a point of reference. I'm not familiar with the details, but I think it
> is header based,

Kind of: the metadata are in header-like "Name: value" lines, but in the
mail body (i.e. after the separating whitespace line).

> which is a big ask for users.

Typically you don't write those by hand (you don't write your mail
or HTTP headers by hand either -- at least not usually).

For command-line junkies there is a `reportbug' utility, which at
the same time collects some system information and prepares the
mail for you. The nice part is that the generated thing is text
based and you /can/ review or change it before sending.

Best of both worlds, I'd say.

There seem to be Emacs helpers for that [1] [2] (but I can't share
any experience on them).

Cheers
[1] https://www.emacswiki.org/emacs/EmacsForDebian
[2] https://www.emacswiki.org/emacs/TinyDebian
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: issue tracker?

[Anthony Carrico]

On 5/21/20 10:18 AM, Anthony Carrico wrote:
> which is a big ask for users.

... given that the community expressed that it would like to interact on
a mailing list without other user facing tooling.

-- 
Anthony Carrico

Re: issue tracker?

[Kévin Le Gouguec]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> - As pointed out, Org has a bug tracker : Emacs' Debbugs. See
>   <https://debbugs.gnu.org/Emacs.html>. Org users do not send bugs
>   through it much.

(In the event that they do, should whoever follows bug-gnu-emacs refer
these users to emacs-orgmode?)

> - Considering the previous point, I doubt switching to a bug tracker
>   today would help handling more bug reports. It will induce more work,
>   though. For example, some triage happens currently on the ML: if
>   a so-called bug report is clearly a misunderstanding, someone here
>   often helps the OP without the developers interfering. This never
>   happens in the bug tracker Org has actually.

I wouldn't be so categoric; it is my impression that there are a number
of lurkers on bug-gnu-emacs who skim through reports that touch on
topics they are interested in[1], and will occasionally pop up to help
the OP.

At least I know I try to do so (cf. bug#41364, about org-mode as it
happens).


[1] I'm saying this based on off-list discussions that sometimes sprout
off bug such reports…  and based on the fact that I do that myself.

Re: issue tracker?

[Kévin Le Gouguec]

Anthony Carrico <acarrico@memebeam.org> writes:

> On 5/21/20 10:18 AM, Anthony Carrico wrote:
>> which is a big ask for users.
>
> ... given that the community expressed that it would like to interact on
> a mailing list without other user facing tooling.

AFAICT, the only thing users have to do to participate in Debbugs
conversations is keeping BUGNUMBER@debbugs.gnu.org in the CC list;
maintainers handle control commands themselves (e.g. tagging, merging,
closing).

Re: issue tracker?

[Eric Abrahamsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> - As pointed out, Org has a bug tracker : Emacs' Debbugs. See
>>   <https://debbugs.gnu.org/Emacs.html>. Org users do not send bugs
>>   through it much.
>
> (In the event that they do, should whoever follows bug-gnu-emacs refer
> these users to emacs-orgmode?)

Maybe a first step would be changing `org-submit-bug-report' to submit
the bug to debbugs, not to this mailing list?

I know I'd be happy to help with bug triage, but I don't go wading
through this mailing list like I used to. I do use debbugs for other
stuff, though, and it would be easy to add an extra filter that I check
regularly.

2¢...

Re: issue tracker?

[Roland Everaert]

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

I will surely state the obvious, but the output of this discussion is that
ther4e is a need for everybody, what ever our relationship to org-mode or
emacs, needs a way to filter the various conversation about org-mode on the
various communication channel used by the project.

This mainly imply this ML and if there is a way to pre-format messages we
want to send to the ML it will make filtering easier.

In fact, a good approach would be the same as for todo state.

Example of message states:
[QUESTION] -> [ANSWER]
[BUG] -> ( [CONFIRMED] | [WONTFIX] | [SOLVED] )
[CONFIRMED] -> ( [SOLVED] | [PLANNED] )
[FEATURE] -> ( [WONTDO] | [PLANNED] | [IMPLEMENTED] )
[PLANNED] -> ( [IMPLEMENTED] | [SOLVED] )

Of Course, nothing should prevent moving a message from [BUG] to [QUESTION]
for example.

Hope this will help go on with a solution and an actual implementation, I
suppose mainly documentation on the org website and configuration for all
of us.

Regards,

Roland.


On Thu, May 21, 2020 at 6:32 PM Eric Abrahamsen <eric@ericabrahamsen.net>
wrote:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
> > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> >
> >> - As pointed out, Org has a bug tracker : Emacs' Debbugs. See
> >>   <https://debbugs.gnu.org/Emacs.html>. Org users do not send bugs
> >>   through it much.
> >
> > (In the event that they do, should whoever follows bug-gnu-emacs refer
> > these users to emacs-orgmode?)
>
> Maybe a first step would be changing `org-submit-bug-report' to submit
> the bug to debbugs, not to this mailing list?
>
> I know I'd be happy to help with bug triage, but I don't go wading
> through this mailing list like I used to. I do use debbugs for other
> stuff, though, and it would be easy to add an extra filter that I check
> regularly.
>
> 2¢...
>
>

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

Re: issue tracker?

[Anthony Carrico]

On 5/22/20 4:17 AM, Roland Everaert wrote:
> Example of message states:
> [QUESTION] -> [ANSWER]
> [BUG] -> ( [CONFIRMED] | [WONTFIX] | [SOLVED] )
> [CONFIRMED] -> ( [SOLVED] | [PLANNED] )
> [FEATURE] -> ( [WONTDO] | [PLANNED] | [IMPLEMENTED] )
> [PLANNED] -> ( [IMPLEMENTED] | [SOLVED] )

I love your enthusiasm. A mailing list has no means to type check 
messages, so I think it does call for a more simplified mechanism, 
especially as a first pass (note that the machine is necessarily 
nondeterministic, since different people can cause it to transition at 
the same time by sending a message).

I'd argue that questions and answers are just normal threads, that don't 
need a state, and issues just need an open state, and a closed state. 
/The details of the of those states are in the threads for anyone who 
cares to look/. So, OPEN/CLOSED and let the threads speak for themselves.

In this way, there are just two kinds of discussions: tracked, and 
untracked. Newbies can quickly pick up the OPEN/CLOSED grammar. People 
can meander threads between the richer states in their discussion, 
hopefully with good subject lines, and 'bots just need to look for one 
pair of keywords, ignoring threads without those keywords. I don't 
actually use emacs for email, but I'm guessing it wouldn't be too hard 
for someone to write an elisp script to scan a mailbox/maildir to gather 
a list of subject lines--is this true?

-- 
Anthony Carrico

Re: issue tracker?

[Ken Mankoff]

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

On Wed, May 20, 2020 at 7:36 PM Anthony Carrico <acarrico@memebeam.org>
wrote:

> Given that the mailing list holds the issues, it would be nice if you
> could import the mailing list into your client as a lump (maildir/mbox).
> Currently you can only download it chunk by chunk, so it isn't really
> practical for a newcomer to import the whole list to do research a new
> issue before reporting it.
>

You can import it. See recent announcement to this list:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00020.html

  -k.

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

Re: issue tracker?

[Roland Everaert]

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

I have to admit that I am kind of a state tracking freak, so, your proposal
is welcomed to keep that tendency at bay.

However, I would add a "category" for bugs/issues and feature requests, in
the subject, else, the bot, the readers and the maintainer will have still
to dig deep into threads to know which one was a feature and which one was
actually a bug report.

There must be also some kind of "protocol" to transition between the
various discussions, like
- from bug to a normal question
- normal question to a feature request

We must avoid that to much bugs ends up as simple discussion, without a
proper sanitation of the thread subject. * I am not sure this is clear even
for me :/*


On Fri, May 22, 2020 at 4:54 PM Anthony Carrico <acarrico@memebeam.org>
wrote:

> On 5/22/20 4:17 AM, Roland Everaert wrote:
> > Example of message states:
> > [QUESTION] -> [ANSWER]
> > [BUG] -> ( [CONFIRMED] | [WONTFIX] | [SOLVED] )
> > [CONFIRMED] -> ( [SOLVED] | [PLANNED] )
> > [FEATURE] -> ( [WONTDO] | [PLANNED] | [IMPLEMENTED] )
> > [PLANNED] -> ( [IMPLEMENTED] | [SOLVED] )
>
> I love your enthusiasm. A mailing list has no means to type check
> messages, so I think it does call for a more simplified mechanism,
> especially as a first pass (note that the machine is necessarily
> nondeterministic, since different people can cause it to transition at
> the same time by sending a message).
>
> I'd argue that questions and answers are just normal threads, that don't
> need a state, and issues just need an open state, and a closed state.
> /The details of the of those states are in the threads for anyone who
> cares to look/. So, OPEN/CLOSED and let the threads speak for themselves.
>
> In this way, there are just two kinds of discussions: tracked, and
> untracked. Newbies can quickly pick up the OPEN/CLOSED grammar. People
> can meander threads between the richer states in their discussion,
> hopefully with good subject lines, and 'bots just need to look for one
> pair of keywords, ignoring threads without those keywords. I don't
> actually use emacs for email, but I'm guessing it wouldn't be too hard
> for someone to write an elisp script to scan a mailbox/maildir to gather
> a list of subject lines--is this true?
>
> --
> Anthony Carrico
>
>

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

Re: issue tracker?

[Russell Adams]

On Sat, May 23, 2020 at 02:57:26PM +0200, Roland Everaert wrote:
> There must be also some kind of "protocol" to transition between the
> various discussions, like
> - from bug to a normal question
> - normal question to a feature request
>

You are aware this is how the Emacs bug mailing list works? They run
Debbugs. Org is part of the Emacs mailing list, and so a tracker is already in
place. Emails with keywords open and close tickets.

https://debbugs.gnu.org/Emacs.html

You can view them online, search, and submit reports directly from Emacs.

Bastien sometimes CC's the Org list with Emacs bugs by number for discussion.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: issue tracker?

[Roland Everaert]

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

No, I was not aware of it.  Yet, if I understand the objective of the Emacs
ML and Debbugs, it is for, when you have a crash with emacs or, at least,
an error stack trace when evaluating some lisp code. This is different from
the intent here to define how to switch a thread started as a simple
conversation to a tracked conversation, as a bug, feature request or
suggestion, an the other way around.

Sorry if I was not clear about it or if I misunderstand the purpose of
Debbugs and the Emacs ML.

Regards,

Roland.

On Sat, May 23, 2020 at 3:16 PM Russell Adams <RLAdams@adamsinfoserv.com>
wrote:

>
> On Sat, May 23, 2020 at 02:57:26PM +0200, Roland Everaert wrote:
> > There must be also some kind of "protocol" to transition between the
> > various discussions, like
> > - from bug to a normal question
> > - normal question to a feature request
> >
>
> You are aware this is how the Emacs bug mailing list works? They run
> Debbugs. Org is part of the Emacs mailing list, and so a tracker is
> already in
> place. Emails with keywords open and close tickets.
>
> https://debbugs.gnu.org/Emacs.html
>
> You can view them online, search, and submit reports directly from Emacs.
>
> Bastien sometimes CC's the Org list with Emacs bugs by number for
> discussion.
>
>
> ------------------------------------------------------------------
> Russell Adams                            RLAdams@AdamsInfoServ.com
>
> PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/
>
> Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
>
>

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

Re: issue tracker?

[Robert Pluim]

>>>>> On Mon, 25 May 2020 13:20:30 +0200, Roland Everaert <reveatwork@gmail.com> said:

    Roland> No, I was not aware of it.  Yet, if I understand the objective of the Emacs
    Roland> ML and Debbugs, it is for, when you have a crash with emacs or, at least,
    Roland> an error stack trace when evaluating some lisp code. This is different from
    Roland> the intent here to define how to switch a thread started as a simple
    Roland> conversation to a tracked conversation, as a bug, feature request or
    Roland> suggestion, an the other way around.

    Roland> Sorry if I was not clear about it or if I misunderstand the purpose of
    Roland> Debbugs and the Emacs ML.

The definition of 'emacs bug' is fairly loose. It ranges from 'emacs
crashed' to 'when I do this funky org-mode thing with 1000 lines of
config, thereʼs an extra space at eol' and everything in between, and
also covers feature requests.

Robert

Re: issue tracker?

[Matthew Lundin]

Detlef Steuer <steuer@hsu-hh.de> writes:

> How to add more now? Same here. Mail is functionally superior to a lot
> of modern solutions.
>
> A Bugtracker you do not use on a regular basis often is a horrible time sink.
> Plus, most of the time you need just another account for a site you
> never wanted an account on. 
>
> Furthermore many of the discussions on this list wouldn't have happend,
> if the first post went into a bugtracker. 
>
> I would go as far as saying *this list* is one of the fastest reacting
> amd friendliest communities I have been part of. The job Nicolas does is
> just awesome.
>
> That leads to the next point: If Nicolas decided *he* would love to work
> with a bugtracker, I would not complain and open an account.
> As it is now, anything that's not in the best interest of our benevolent
> developer, should not even be considered :-)

I agree wholeheartedly with everything Detlef says here. Due to life
circumstances, I have only been able to participate intermittently on
the mailing list over the past 10 years. But I have happily used Org
during that time, and I love that that this ML has been a constant in
the Org Mode community, even as countless other tech fads have come and
gone.

Matt

Re: issue tracker?

[Matthew Lundin]

Anthony Carrico <acarrico@memebeam.org> writes:

> Given that the mailing list holds the issues, it would be nice if you 
> could import the mailing list into your client as a lump (maildir/mbox). 
> Currently you can only download it chunk by chunk, so it isn't really 
> practical for a newcomer to import the whole list to do research a new 
> issue before reporting it.

You can use wget to download them all the mbox files at once here:

https://lists.gnu.org/archive/mbox/emacs-orgmode/

For instance, the following command...

wget -r -nH --cut-dirs=2 --no-parent -A "2019-*" --reject="index.html*" https://lists.gnu.org/archive/mbox/emacs-orgmode/

..will download all mbox archives from 2019 into the directory
emacs-orgmode.

Then you can browse them in Gnus, cat them into a single file for easier
importing into a client, convert them to Maildir (via mb2md) for
indexing in notmuch, mu4e, etc.

Matt

Re: issue tracker?

[Mario Frasca]

myself, I recently posted a patch, received zero reaction, and have the 
impression it's now lost in the logs of this mailing list.  indeed 
pretty inefficient!

something which flashed to my mind while writing this email: we're 
dealing with an emacs software, part of emacs, can we just use M-x 
report-emacs-bug?

cheers, MF

On 19/05/2020 09:58, Bruce D'Arcus wrote:
> Regardless, doing issue tracking, discussion, and patch submission on 
> a ML in 2020 is pretty odd and inefficient.
>
> I would have submitted feedback here 6-12 months earlier than I did if 
> org had a proper issue tracker.

Re: issue tracker?

[Russell Adams]

On Wed, May 27, 2020 at 12:59:24PM -0500, Mario Frasca wrote:
> myself, I recently posted a patch, received zero reaction, and have the
> impression it's now lost in the logs of this mailing list.  indeed
> pretty inefficient!

Or the devs haven't had a chance yet.

> something which flashed to my mind while writing this email: we're
> dealing with an emacs software, part of emacs, can we just use M-x
> report-emacs-bug?

Yes, I believe that goes to the emacs bug list.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: issue tracker?

[Eric Abrahamsen]

Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> On Wed, May 27, 2020 at 12:59:24PM -0500, Mario Frasca wrote:
>> myself, I recently posted a patch, received zero reaction, and have the
>> impression it's now lost in the logs of this mailing list.  indeed
>> pretty inefficient!
>
> Or the devs haven't had a chance yet.
>
>> something which flashed to my mind while writing this email: we're
>> dealing with an emacs software, part of emacs, can we just use M-x
>> report-emacs-bug?
>
> Yes, I believe that goes to the emacs bug list.

And if you put:

Package: org

As the first line in the report, it will automatically be tagged as org,
making it easier for people to find. (At least, I'm pretty sure that
will work correctly.)

Re: issue tracker?

[Russell Adams]

On Wed, May 27, 2020 at 12:59:24PM -0500, Mario Frasca wrote:
> myself, I recently posted a patch, received zero reaction, and have the
> impression it's now lost in the logs of this mailing list.  indeed
> pretty inefficient!

Have to point out, that you received replies after about a week. Remember OSS
projects are run by volunteers, and your patch is about a very specific
sub-function. Eventually someone did reach out to you about it, and you appear
to be having a pretty good exchange over the patch.

I don't see how any other solution would have helped. Your patch still would
have waited for someone with relevant experience to look at it.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: issue tracker?

[Bastien]

Hi Eric,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Maybe a first step would be changing `org-submit-bug-report' to submit
> the bug to debbugs, not to this mailing list?

I'd like to keep this mailing list as the central place to discuss
everything about Org, including bug reports.

When Org bugs are reported through M-x report-emacs-bug, chances are
that they are against an old version of Org, the one that comes with
Emacs.  I think it's good like it is: because we can easily guess
whether the bug is because Org is outdated or if it is an important
bug, still present in the stable version of Org.

-- 
 Bastien

Re: issue tracker?

[Bastien]

Hi Roland,

Roland Everaert <reveatwork@gmail.com> writes:

> [QUESTION] -> [ANSWER]
> [BUG] -> ( [CONFIRMED] | [WONTFIX] | [SOLVED] )
> [CONFIRMED] -> ( [SOLVED] | [PLANNED] )
> [FEATURE] -> ( [WONTDO] | [PLANNED] | [IMPLEMENTED] )
> [PLANNED] -> ( [IMPLEMENTED] | [SOLVED] )

as others in this thread, I'm skeptical about this approach, tracking
the various states from the subject line seems fragile.

That said, I encourage everyone on the list to freely use whatever
relevant label in the subject line: something like [HELP] clearly
states that someone is looking for help, and something like [BUG]
that this is a bug report.

-- 
 Bastien

Re: issue tracker?

[Bastien]

I also wholeheartedly agree with Matt and Detlef: I find emails to be 
the best way to deal with bug reports.

Matthew Lundin <mdl@imapmail.org> writes:

> I agree wholeheartedly with everything Detlef says here. Due to life
> circumstances, I have only been able to participate intermittently on
> the mailing list over the past 10 years. But I have happily used Org
> during that time, and I love that that this ML has been a constant in
> the Org Mode community, even as countless other tech fads have come and
> gone.

Your input keeps being valuable, as it used to be, so thanks!

-- 
 Bastien

Re: issue tracker?

[Bastien]

Hi Mario,

Mario Frasca <mario@anche.no> writes:

> myself, I recently posted a patch, received zero reaction, and have
> the impression it's now lost in the logs of this mailing list.  indeed 
> pretty inefficient!

Sorry for that.  

As others have mentioned, Org developers are working on their free
time to help others, fix bugs and keep Org alive.

If you think your patch got lost and should be considered, please
revive the thread.

Thanks,

-- 
 Bastien

Re: issue tracker?

[Bastien]

Hi Anthony,

Anthony Carrico <acarrico@memebeam.org> writes:

> Does org-mode have an issue tracker, to keep track of which issues
> are active, or is it just this mailing list?

thanks for asking.  

I've skimmed through https://orgmode.org/worg/org-faq.html and the
question "Does org-mode have an issue tracker?" is not there, while
it's probably the most frequently asked question :)

As Nicolas pointed out, the main issue is the lack of maintainers, not
the absence of a bug tracker -- otherwise Org would have died years
ago!

One thing we can do is to recruit developers: I will discuss it
with Kyle and Nicolas and see if it sounds useful to them, and for
what area of the code.  (For example, I would love to have someone
responsible for Org Babel, someone for Worg, someone for important
export backends, etc.)

While I think a bug tracker is no magical solution (and can even add
more to the current problem of our lack of resources), I agree there
is still something we can do better: not losing reports of confirmed
bugs.

I have setup this page on orgmode.org which now tracks confirmed bugs:

  https://updates.orgmode.org

Org developers can subscribe to this RSS feed:
https://updates.orgmode.org/feed/bugs

And bugs are also available as json data:
https://updates.orgmode.org/data/bugs

Anyone on the list can "confirm" a bug by adding this header:

  X-Woof-Bug: confirmed

I hope this will help us move in the right direction while still using
the list for *every* kind of input*.

Best,

-- 
 Bastien

Re: issue tracker?

[Mario Frasca]

Hi Bastien,

in the meanwhile someone found the patch, and we are working on it.

thank you for the feedback!

but it stays confusing, and sure I get the point, people here are 
volunteers, working on their free time, but precisely for this reason it 
would be better if we could rely on some more focused / focusing tool 
for working on patches.

while working on my contribution, I'm also reading the code I'm adding 
to, and I am tempted to perform unrelated edits, like correcting a 
docstring to a function that does something, just not quite what the 
docstring says, or refactoring stuff in order to add missing unit tests, 
but that way my patch would not focus on the task of adding this small 
piece of functionality.

it's several unrelated edits, and if we were to do this via email, it 
would cost all of us so much time, that I think I'll better leave it.

ciao, best regards, MF

On 01/06/2020 09:45, Bastien wrote:
> Hi Mario,
>
> Mario Frasca <mario@anche.no> writes:
>
>> myself, I recently posted a patch, received zero reaction, and have
>> the impression it's now lost in the logs of this mailing list.  indeed
>> pretty inefficient!
> Sorry for that.
>
> As others have mentioned, Org developers are working on their free
> time to help others, fix bugs and keep Org alive.
>
> If you think your patch got lost and should be considered, please
> revive the thread.
>
> Thanks,
>

Re: issue tracker?

[Bastien]

Hi Mario,

Mario Frasca <mario@anche.no> writes:

> while working on my contribution, I'm also reading the code I'm adding
> to, and I am tempted to perform unrelated edits, like correcting a 
> docstring to a function that does something, just not quite what the
> docstring says, or refactoring stuff in order to add missing unit
> tests, but that way my patch would not focus on the task of adding
> this small piece of functionality.
>
> it's several unrelated edits, and if we were to do this via email, it
> would cost all of us so much time, that I think I'll better leave it.

It cost time only if we have to discuss your changes.

If you are confident you can get commit access and apply your changes
without discussing them first, then let's just go ahead with giving
you write access.

But in general we do require that people get familiar with the way we
expect contributions before giving write access.

Let us know what would help you contribute more.

Best,

-- 
 Bastien

Re: issue tracker?

[Mario Frasca]

On 01/06/2020 10:53, Bastien wrote:
> Let us know what would help you contribute more.

as mentioned, I would like to correct docstrings, refactor the code in a 
few points, and add unit tests.

---

(defun org-plot/gnuplot-script (data-file num-cols params &optional preface)
   "Write a gnuplot script to DATA-FILE respecting the options set in 
PARAMS.

this is not what the function does: DATA-FILE is purely a string, the 
name of the file containing the data, and the function returns the 
script as a string, which refers to DATA-FILE.

in practice, the author could have left the DATA-FILE parameter 
altogether, used a placeholder, say %DATAFILE%, and replaced it in the 
returned string.  but it works, and I would not fix it, except for the 
docstring, which is misleading.

---

(defun org-plot/goto-nearest-table ()
   "Move the point to the beginning of nearest table.
Moves back if the point is currently inside of table, otherwise
forward to next table.  Return value is the point."

this is what the function does, but the current docstring says

(defun org-plot/goto-nearest-table ()
   "Move the point forward to the beginning of nearest table.
Return value is the point at the beginning of the table."

where "nearest" is not defined.

---

collecting options is a candidate for refactoring:

       (save-excursion (while (and (equal 0 (forward-line -1))
                   (looking-at "[[:space:]]*#\\+"))
             (setf params (org-plot/collect-options params))))

this is how it is used, inside of the exposed command org-plot/gnuplot.

---

If I understood my other reviewer Kyle Meyer correctly, he was 
suggesting that usage of setf instead of setq in this source was not 
exactly appropriate, and I think it is only necessary in one case, the 
others can be replaced with setq.

but then again, fixing something that works and has no unit tests, may 
be a recipe for future failure.

---

there are other minor mistakes in the code and in the documentation, 
which are quite unrelated, like formatting …

       (let ((num-rows (length table)) (num-cols (length (nth 0 table)))
         (gnuplot-row (lambda (col row value)

notice how this let has three clauses, but they fit on two lines.

or simply typing =dep= instead of =deps=.

---

I've not been collecting them, this is just the few that I can recall, 
and would like to correct them, but in order to make my contribution 
only touch the code I want to add, I refrain from doing so.

best regards, MF

Re: issue tracker?

[Russell Adams]

On Mon, Jun 01, 2020 at 11:28:48AM -0500, Mario Frasca wrote:
> On 01/06/2020 10:53, Bastien wrote:
> > Let us know what would help you contribute more.
>
> as mentioned, I would like to correct docstrings, refactor the code in a
> few points, and add unit tests.
>
> I've not been collecting them, this is just the few that I can recall,
> and would like to correct them, but in order to make my contribution
> only touch the code I want to add, I refrain from doing so.

What's so hard about fixing those in a git clone, generating a diff, and posting
to the ML? You took more time just now to write them down.

In 30 second search I find:
https://thoughtbot.com/blog/send-a-patch-to-someone-using-git-format-patch

Says to use 'git format-patch', and then email the resulting file. Bastien and
other maintainers can just import your patch then.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: issue tracker?

[Vladimir Nikishkin]

Does any other email client apart from Gnus support adding additional headers?

-- 
Yours sincerely, Vladimir Nikishkin

Re: issue tracker?

[Bastien]

Hi Vladimir,

Vladimir Nikishkin <lockywolf@gmail.com> writes:

> Does any other email client apart from Gnus support adding
> additional headers?

M-x mail RET
M-x compose-mail RET

And surely quite a few other email clients, even outside Emacs.

If a user cannot set the headers herself, that's not a problem:
someone with this ability can help with the bug triage anyway.

Also, let me make something more clear: we don't want all emails
from M-x org-submit-bug-report to be flagged as "bug" - because
many are not real bugs.  The manual confirmation step is here to
help flagging the relevant entries only (not flagging bugs that
are immediatey fixed neither.)

I hope it makes sense to you.

-- 
 Bastien

Re: issue tracker?

[Bastien]

Hi Mario,

Mario Frasca <mario@anche.no> writes:

> On 01/06/2020 10:53, Bastien wrote:
>> Let us know what would help you contribute more.
>
> as mentioned, I would like to correct docstrings, refactor the code in
> a few points, and add unit tests.

Please go ahead.  Read https://orgmode.org/worg/org-contribute.html
and submit your first patch following the rules we have for the commit
messages (they are not easily understood for newcomers).  After a few
well-formatted useful patches, we can perhaps add you as a committer.

Thanks,

-- 
 Bastien 

Re: issue tracker?

[Mario Frasca]

On 02/06/2020 06:57, Bastien wrote:
> Please go ahead.  Readhttps://orgmode.org/worg/org-contribute.html
> and submit your first patch following the rules we have for the commit
> messages (they are not easily understood for newcomers).  After a few
> well-formatted useful patches, we can perhaps add you as a committer.

I sent the pdf for contributing, and I have a question on how to use 
this email-based issue tracker:

how do I get the list of open issues?  complete with the status 
accepted/wont-fix/whatever?

best regards

Re: issue tracker?

[Bastien]

Hi Mario,

Mario Frasca <mario@anche.no> writes:

> I sent the pdf for contributing, and I have a question on how to use
> this email-based issue tracker:

Beware that this is not meant to be an issue tracker.

> how do I get the list of open issues?  complete with the status
> accepted/wont-fix/whatever?

Please read these two announcements:

https://orgmode.org/list/87y2p64xo7.fsf@gnu.org/
https://orgmode.org/list/87ftbe2487.fsf@gnu.org/

Let me know if you have any question.

Best,

-- 
 Bastien

Re: issue tracker?

[Mario Frasca]

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

Hi Bastien,

> The tool is experimental: if it proves useful, let's try to keep it,
> otherwise let's drop it: our main focus should be in recruiting new
> developers to help with the codebase.

very interesting approach.

sounds like you don't want to manage the status changes a bit tighter.  
I know, I can check the code, but it's more practical if we mention it 
here explicitly.  anybody can send status change emails?  I mean, this 
is an open list, anybody who just knows how to put a header to an email 
can confirm a bug?  on the other hand, I never tried to add extra 
headers using thunderbird.

apart from the technical aspect, I would suggest: anybody can 'vote-for' 
a bug, and you keep a counter on voted-for.   but only a maintainer can 
'confirm' (that fixing that bug is desirable). then we new contributors 
can choose which confirmed bug is easy enough for us to make an 
attempt.  or which fits our interests and skills.  or which has 
accumulated most votes, hasn't been rejected, so we can remind the 
maintainer.

… if the "main focus" is recruiting, I would also suggest a category 
"good first issue".

On 06/06/2020 02:57, Bastien wrote:
> Hi Mario,
>
> Beware that this is not meant to be an issue tracker.

I understand, not a bug "tracking" tool, but it sounds like it's able to 
shed some light in the dark.

thank you and cheers,

Mario


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

Re: issue tracker?

[Bastien]

Hi Mario,

Mario Frasca <mario@anche.no> writes:

> very interesting approach. 

Thanks for looking more closely into it.

> sounds like you don't want to manage the status changes a bit
> tighter.  I know, I can check the code, but it's more practical if we
> mention it here explicitly.  anybody can send status change emails? 

Yes, anybody can confirm a bug and anybody can mark it as fixed.

> I mean, this is an open list, anybody who just knows how to put a
> header to an email can confirm a bug? 

Yes. The pattern I've seen in the last 15 ten years is that someone
sends a bug report and 50% of the time it is not really possible to
reproduce the bug.  And people who reproduce bugs are not always code
contributors, they can be "power users", so I think it's safe to allow
anyone to confirm a bug -- that's something that really helps.

> on the other hand, I never tried to add extra headers using
> thunderbird.

Yes, you can:

https://www.lifewire.com/arbitrary-custom-heading-email-thunderbird-1173089

> apart from the technical aspect, I would suggest: anybody can
> 'vote-for' a bug, and you keep a counter on voted-for.

It would require people to register on updates.orgmode.org.
I'm not sure the expected benefit is really worth it for now.

> but only a maintainer can 'confirm' (that fixing that bug is
> desirable). 

I think it is important that anyone can confirm a bug.

> then
> we new contributors can choose which confirmed bug is easy enough for
> us to make an attempt.  or which fits our interests and skills.  or
> which has accumulated most votes, hasn't been rejected, so we can
> remind the maintainer.
>
> … if the "main focus" is recruiting, I would also suggest a category
> "good first issue".

I have seen "good first issues" in many repositories and I don't think
it is sufficient as a way to attract new contributors: those tags are
useful when you also actively organize the contribution and the
onboarding of new contributors.

Also, "good first issues" are often those we can fix very easily and
there is no good reason not to fix them.

That said, I would love to organize a hackathon for Org-mode where
people would gather online for one day, exchange ideas, break and fix
things, propose new features, etc.  That is, IMHO, the way to recruit
new contributors, on top of simply formally asking "who would like to
be in charge of X, Y and Z?"

> I understand, not a bug "tracking" tool, but it sounds like it's able
> to shed some light in the dark.

Yes, I hope so!

-- 
 Bastien

Re: issue tracker?

[Mario Frasca]

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

good day Bastien

On 07/06/2020 04:38, Bastien wrote:
>> anybody can
>> 'vote-for' a bug, and you keep a counter on voted-for.
> It would require people to register on updates.orgmode.org.
> I'm not sure the expected benefit is really worth it for now.

why would it?  you already trust email senders on identity and integrity 
in all ways, you can also add this one.  a user is an email address.  
the benefit, in my eyes, is for you to have a measure of the opinion of 
(voiceful) users.

>> a maintainer can 'confirm' (that fixing that bug is
>> desirable).
> I think it is important that anyone can confirm a bug.

I see differences among -confirming a behaviour, -confirming that a 
behaviour is a bug, -asserting that a maintainer would accept a 
"correction".  please drop the subject if you don't want me to argue in 
favour of something you have already discarded.

> That said, I would love to organize a hackathon for Org-mode where
> people would gather online for one day, exchange ideas, break and fix
> things, propose new features, etc.  That is, IMHO, the way to recruit
> new contributors, on top of simply formally asking "who would like to
> be in charge of X, Y and Z?"

I like the `#emacs' irc chatroom on freenode, I discovered it recently.  
the more specific chatroom `#org-mode' is less active but not less 
welcoming.  it was there where I got the hint to write here, and where 
they told me "no need to subscribe".  or open a new temporary room, but 
I hope we stay with IRC, which we can use from within an emacs buffer.

ciao, Mario



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

Re: issue tracker?

[Bastien]

Hi Mario,

> On 07/06/2020 04:38, Bastien wrote:
>
>         anybody can
>         'vote-for' a bug, and you keep a counter on voted-for.
>         
>     It would require people to register on updates.orgmode.org.
>     I'm not sure the expected benefit is really worth it for now.
>     
> why would it?  you already trust email senders on identity and
> integrity in all ways, you can also add this one.  

Yes, indeed.  But it would add a bit of complexity as I would need to
register the votes somehow.  

I'd rather see if people start using "X-Woof-Bug: confirmed" for bugs
before handling "X-Woof-Bug: vote" or something.

> a user is an email address.  the benefit, in my eyes, is for you to
> have a measure of the opinion of (voiceful) users.

Still, a confirmed bug is something that needs to be fixed, and I'd
rather have people spend time on confirming bugs than on voting for
them.  Let's see later on if your idea gets more support.

>         a maintainer can 'confirm' (that fixing that bug is
>         desirable). 
>         
>     I think it is important that anyone can confirm a bug.
>     
> I see differences among -confirming a behaviour, -confirming that a
> behaviour is a bug, -asserting that a maintainer would accept a
> "correction".  please drop the subject if you don't want me to argue
> in favour of something you have already discarded.

I don't discard anything, and discussion is always fine.  It is just
that I don't want to overengineer something that has not proved its
efficacity yet.  Maybe later.

>     That said, I would love to organize a hackathon for Org-mode where
>     people would gather online for one day, exchange ideas, break and fix
>     things, propose new features, etc.  That is, IMHO, the way to recruit
>     new contributors, on top of simply formally asking "who would like to
>     be in charge of X, Y and Z?"
>     
> I like the `#emacs' irc chatroom on freenode, I discovered it
> recently.  the more specific chatroom `#org-mode' is less active but
> not less welcoming.  it was there where I got the hint to write here,
> and where they told me "no need to subscribe".  or open a new
> temporary room, but I hope we stay with IRC, which we can use from
> within an emacs buffer.

I don't spend time on #org-mode but I've heard this is a nice place,
I'm glad some people are welcoming new users/contributors there.

Best,

-- 
 Bastien

Re: issue tracker?

[Bastien]

Bastien <bzg@gnu.org> writes:

> I have setup this page on orgmode.org which now tracks confirmed bugs:
>
>   https://updates.orgmode.org

I've updated https://updates.orgmode.org

The main change is that Woof! now tracks help requests separately.

You can publish a help request on the list by adding this header in
the mail you send to this list:

  X-Woof-Help: confirmed

See https://github.com/bzg/woof#usage for more.

-- 
 Bastien