~sircmpwn/sr.ht-discuss

6 5

Possibility to add labels to todo

Details
Message ID
<20230416195341.0b20bda8a213c8cb868d711f@posteo.net>
DKIM signature
missing
Download raw message
Hi,

Can you please implement some way to add or remove labels to a task via email?

Something like

!labels add "this" "that also is a long label"
!labels remove "this"

What do you think?

It's annoying thing to be logged to do such thing but just comment to change the state of the task

Thanks in advance,
Xavier
Details
Message ID
<87h6tfbk1h.fsf@city17.xyz>
In-Reply-To
<20230416195341.0b20bda8a213c8cb868d711f@posteo.net> (view parent)
DKIM signature
missing
Download raw message
> Can you please implement some way to add or remove labels to a task via email?
>
> Something like
>
> !labels add "this" "that also is a long label"
> !labels remove "this"

Personally I find the idea interesting but I'm afraid it would require a
"bot" server-side parsing the command and then sending an HTTP query to
todo.sr.ht. I don't know if sourcehut has the infrastructure ready for that.

What you want could be accomplished by scripting a GraphQL client (I
have one in bash for testing).
Details
Message ID
<jwv354za3fi.fsf-monnier+Inbox@gnu.org>
In-Reply-To
<20230416195341.0b20bda8a213c8cb868d711f@posteo.net> (view parent)
DKIM signature
missing
Download raw message
> Can you please implement some way to add or remove labels to a task via email?

Even better would be to keep this kind of data in a Git repository, so
you can edit it on your machine and then push it to SourceHut.


        Stefan
Details
Message ID
<CRYRA4MCJC62.2HRCMK1LOEXU8@hades.moritz.sh>
In-Reply-To
<jwv354za3fi.fsf-monnier+Inbox@gnu.org> (view parent)
DKIM signature
missing
Download raw message
On Mon Apr 17, 2023 at 12:07 AM CEST, Stefan Monnier wrote:
> Even better would be to keep this kind of data in a Git repository, so
> you can edit it on your machine and then push it to SourceHut.

I disagree, this would be a terrible solution. This would either require push
access for people to file bugs, or allow flooding the repo with bogus reports
that may or may not be removable from history.

I think a way similar to how lists handles patchset status would be better.

X-Sourcehut-Assigned-User: ~mpldr,~ferdinandyb
X-Sourcehut-Issue-Labels: bug,database,-stale (add "bug" and "database", remove "stale")
X-Sourcehut-Issue-Status: DUPLICATE

-- 
Moritz Poldrack
https://moritz.sh
Details
Message ID
<20230417124110.36ndvad2j6rav3bd@lite.local.umgeher.org>
In-Reply-To
<CRYRA4MCJC62.2HRCMK1LOEXU8@hades.moritz.sh> (view parent)
DKIM signature
missing
Download raw message
On Mon, Apr 17, 2023 at 06:51:36AM +0200, Moritz Poldrack wrote:
> On Mon Apr 17, 2023 at 12:07 AM CEST, Stefan Monnier wrote:
> I think a way similar to how lists handles patchset status would be better.
> 
> X-Sourcehut-Assigned-User: ~mpldr,~ferdinandyb
> X-Sourcehut-Issue-Labels: bug,database,-stale (add "bug" and "database", remove "stale")
> X-Sourcehut-Issue-Status: DUPLICATE

indeed!
Details
Message ID
<jwvr0si8r0k.fsf-monnier+Inbox@gnu.org>
In-Reply-To
<CRYRA4MCJC62.2HRCMK1LOEXU8@hades.moritz.sh> (view parent)
DKIM signature
missing
Download raw message
>> Even better would be to keep this kind of data in a Git repository, so
>> you can edit it on your machine and then push it to SourceHut.
> I disagree, this would be a terrible solution. This would either require push
> access for people to file bugs, or allow flooding the repo with bogus reports
> that may or may not be removable from history.

I assumed you'd only give push access to some users.  So I guess what
you're saying is that my suggestion would only solve the problem for
those lucky ones with push access.  So, indeed, whichever way it's
stored, we'd want to offer an email-based way to manipulate that info.

[ To give some background, I'd like to see forges like SourceHut become
  less centralized, e.g. allowing "pull requests" from branches hosted
  anywhere on the Internet (and in this respect SourceHut is currently
  the closest thing to what I want).  I've been playing with a Git based
  issue tracker (https://gitlab.com/monnier/bugit/).  I currently have
  3 proof-of-concept UIs: a command-line one (inspired by Git), an
  email-based one (inspired by Debbugs), and a web one (integrated into
  an older version of Gitea).  And yes, against all odds, I don't yet
  have an Emacs-based UI for it :-)  ]


        Stefan
Details
Message ID
<20230417221447.ee213d21d66c5e616d1469a6@posteo.net>
In-Reply-To
<jwvr0si8r0k.fsf-monnier+Inbox@gnu.org> (view parent)
DKIM signature
missing
Download raw message
I don't know what technical background is necessary to do that. I'm saying that from user perspective: not to login for adding tags, as we could close bugs.


On Mon, 17 Apr 2023 11:48:17 -0400
Stefan Monnier <monnier@iro.umontreal.ca> ha escrit:

> >> Even better would be to keep this kind of data in a Git repository, so
> >> you can edit it on your machine and then push it to SourceHut.
> > I disagree, this would be a terrible solution. This would either require push
> > access for people to file bugs, or allow flooding the repo with bogus reports
> > that may or may not be removable from history.
> 
> I assumed you'd only give push access to some users.  So I guess what
> you're saying is that my suggestion would only solve the problem for
> those lucky ones with push access.  So, indeed, whichever way it's
> stored, we'd want to offer an email-based way to manipulate that info.
> 
> [ To give some background, I'd like to see forges like SourceHut become
>   less centralized, e.g. allowing "pull requests" from branches hosted
>   anywhere on the Internet (and in this respect SourceHut is currently
>   the closest thing to what I want).  I've been playing with a Git based
>   issue tracker (https://gitlab.com/monnier/bugit/).  I currently have
>   3 proof-of-concept UIs: a command-line one (inspired by Git), an
>   email-based one (inspired by Debbugs), and a web one (integrated into
>   an older version of Gitea).  And yes, against all odds, I don't yet
>   have an Emacs-based UI for it :-)  ]
> 
> 
>         Stefan
> 
Reply to thread Export thread (mbox)