Re: Need help with GitHub Issues migration

--===============9054690046723127224==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C18F4563-E254-46E9-B3EA-22B545FEDEF2"


--Apple-Mail=_C18F4563-E254-46E9-B3EA-22B545FEDEF2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 23. Feb 2025, at 15:38, Oswald Buddenhagen via mc-devel =
<mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org> wrote:
>=20
> On Sat, Feb 22, 2025 at 07:38:49PM +0100, Yury V. Zaytsev via mc-devel =
wrote:
>> Hi there, [...]
>>=20
> if you had posted this as a project discussion on github, i could =
click
> "like" now. :-D

That's much appreciated. It's been a crazy amount of work and I'm not =
even done yet...

> (the serious question behind this is: do we want to phase out the list
> in favor of github discussions? it's obviously a separate thing, but =
in
> this context it kind of suggests itself.)

TLDR; if you have a plan and want to volunteer to set up and actively =
participate in a moderated community with discussions, then let's =
discuss the plan and implement it after the move. Otherwise, I'd rather =
leave it for now. I have no time and no interest, and I don't want to =
have yet another unmoderated and languishing avenue associated with the =
project. I've seen people ask questions on StackOverflow, for example, =
and I'm all for that.

Longer version:

The lists don't require any maintenance from me since they are hosted by =
OSU OSL (God bless your soul, Lance!) and the traffic is pretty much =
non-existent. That means I don't have a strong urge to do anything about =
them.

The last time this issue came up was when Gnome was shutting down the =
service and moving everyone over to Discourse. At that time, my =
understanding was that there was strong opposition to Discourse and a =
desire to continue with the mailing lists. So I started negotiating to =
move them to the hosted Mailman instance at OSU OSL, and thankfully they =
agreed.

I'm not opposed to GitHub discussions, but I think it brings up a =
broader question of whether we want to have a "real" community around =
mc, what it should look like, and who is going to put work into it.

I'm actually pretty unhappy about interfacing with users most of the =
time. There are some rare exceptions when people come in with quality =
bug reports or even patches, are polite, respectful and helpful. Sadly, =
I don't think I've ever experienced a test other than from mooffie. =
(Thank you! You were definitely one of the best people I've ever worked =
with).

But most of the time, at best, you get garbage reports that take forever =
to deal with. I don't know what ideas users have about my or "our" =
circumstances (or if they have any ideas at all, or if it's just a =
cultural default). Somehow, not only do they come with an entitlement to =
commercial-grade support with SLAs, they are usually outright abusive. =
Any request for them to invest their time to help fix the problem is =
either ignored or met with hostility.

We get blamed for not fixing bugs fast enough and well enough, and =
otherwise not maintaining the project to a high enough standard. Which =
isn't even wrong, but it only hurts more because I would argue that I =
have at least a decade's worth of track record of doing really amazing =
things on a budget and to a high standard... but the thing is, there is =
no budget. And there is only so much that even the most gifted genius =
can do in a few hours on a weekend on a 30 year old grown and complex =
project.

I don't know if the mere fact that the two of us are still working on =
the project is keeping all the amazing, productive, and resourceful =
developers in the world away, and if we leave with a bang, the project =
will immediately be rebooted in a way that is so much better than it has =
ever been. Somehow I'm skeptical.

So my current thinking is to improve and modernize the development =
infrastructure as much as I can, and maybe that will eventually attract =
more sane contributors to share the work with. If enough work is shared, =
there will be some real development going on, and discussions might be a =
good place to have err... discussions about it. At least upgrading the =
infrastructure and fixing bugs does not hurt the project in my opinion.

>> Unfortunately, the authorship of the posts cannot be transferred.
>>=20
> yeah ...
>=20
> i wonder whether you could automatically set the watchers on issues
> based on inferred participants, though? filtering by mentions would =
also
> work, but only for the old issues, while new ones won't necessarily =
have
> them. being able to filter by "watcher:..." would catch both.

It is not possible to add watchers to issues using the API. However, =
GitHub will consider you a member of a conversation if you're mentioned =
in the issue and/or a comment, and will send you updates if you haven't =
disabled it in your profile. So I'm translating Trac usernames into =
mentions of GitHub handles where I can. I tried that in this issue:

https://github.com/MidnightCommander/mc-test-1/issues/28

I hope you've been notified. If not, I'm afraid there's nothing we can =
do.

>=20
>> * Component (labels)
>> - adm: "area: adm"
>>=20
> maybe put it in a separate repo instead? depends on whether you want =
to
> create a separate repo for issues or want to attach them to the main
> repo (i'd go with the latter).

I want to have the same repository for code and issues, so that ticket =
references in the code can be linked to the issues, and commit =
references in the issues can be linked to the code. Unfortunately, this =
means we'll have to swap repositories, but I'm afraid there's no way =
around it.

I would rather keep tasks in the same repository for now. We can see if =
we can split things up later. I'd rather not start splitting things too =
much. And I think so far it has been a pretty small part of the tickets.

>=20
>> - translates: "area: i18n"
>> - locale: "area: i18n"
>> - translations: "area: i18n"
>>=20
> pedantically, translations are l10n.
> from experience i can say that users get this almost always wrong, but
> assigning components is mostly a maintainer thing in mc anyway.

That is correct, but this component has received tickets for both =
translation (l10n) and internationalization (i18n). I don't think "area: =
i18n & l10n" looks much better and makes it clearer. Is it better now or =
not?

https://github.com/MidnightCommander/mc-test-1/issues

>=20
>> * Resolution (partly labels, partly status)
>>=20
> a bit of a mess, but i wouldn't know how to fix it.
> i know that issue types can be configured at the organization level, =
but
> i have no idea what else.

Yes, I agree that this is suboptimal. Unfortunately, there are only =
built-in resolutions and you can't change them. Also, you get the =
resolution "fixed" on import whether you want it or not. I guess we'll =
have to live with the "worksfome" and "invalid" labels.




--Apple-Mail=_C18F4563-E254-46E9-B3EA-22B545FEDEF2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: =
after-white-space;"><br><div><blockquote type=3D"cite"><div>On 23. Feb =
2025, at 15:38, Oswald Buddenhagen via mc-devel =
&lt;mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>On Sat, Feb 22, 2025 at =
07:38:49PM +0100, Yury V. Zaytsev via mc-devel wrote:<br><blockquote =
type=3D"cite">Hi there, [...]<br><br></blockquote>if you had posted this =
as a project discussion on github, i could click<br>"like" now. =
:-D<br></div></div></blockquote><div><br></div><div>That's much =
appreciated. It's been a crazy amount of work and I'm not even done =
yet...</div><br><blockquote type=3D"cite"><div><div>(the serious =
question behind this is: do we want to phase out the list<br>in favor of =
github discussions? it's obviously a separate thing, but in<br>this =
context it kind of suggests =
itself.)<br></div></div></blockquote><div><br></div><div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">TLDR; if you =
have a plan and want to volunteer to set up and actively participate in =
a moderated community with discussions, then let's discuss the plan and =
implement it after the move. Otherwise, I'd rather leave it for now. I =
have no time and no interest, and I don't want to have yet another =
unmoderated and languishing avenue associated with the =
project.&nbsp;I've seen people ask questions on StackOverflow, for =
example, and I'm all for that.</div></div><div><br></div><div>Longer =
version:</div><div><br></div><div><div>The lists don't require any =
maintenance from me since they are hosted by OSU OSL (God bless your =
soul, Lance!) and the traffic is pretty much non-existent. That means I =
don't have a strong urge to do anything about =
them.</div><div><br></div><div>The last time this issue came up was when =
Gnome was shutting down the service and moving everyone over to =
Discourse. At that time, my understanding was that there was strong =
opposition to Discourse and a desire to continue with the mailing lists. =
So I started negotiating to move them to the hosted Mailman instance at =
OSU OSL, and thankfully they agreed.</div><div><br></div><div>I'm not =
opposed to GitHub discussions, but I think it brings up a broader =
question of whether we want to have a "real" community around mc, what =
it should look like, and who is going to put work into =
it.</div><div><br></div><div>I'm actually pretty unhappy about =
interfacing with users most of the time. There are some rare exceptions =
when people come in with quality bug reports or even patches, are =
polite, respectful and helpful. Sadly, I don't think I've ever =
experienced a test other than from mooffie. (Thank you! You were =
definitely one of the best people I've ever worked =
with).</div><div><br></div><div>But most of the time, at best, you get =
garbage reports that take forever to deal with. I don't know what ideas =
users have about my or "our" circumstances (or if they have any ideas at =
all, or if it's just a cultural default). Somehow, not only do they come =
with an entitlement to commercial-grade support with SLAs, they are =
usually outright abusive. Any request for them to invest their time to =
help fix the problem is either ignored or met with =
hostility.</div></div><div><br></div><div>We get blamed for not fixing =
bugs fast enough and well enough, and otherwise not maintaining the =
project to a high enough standard. Which isn't even wrong, but it only =
hurts more because I would argue that I have at least a decade's worth =
of track record of doing really amazing things on a budget and to a high =
standard... but the thing is, there is no budget. And there is only so =
much that even the most gifted genius can do in a few hours on a weekend =
on a 30 year old grown and complex project.</div><div><br></div><div>I =
don't know if the mere fact that the two of us are still working on the =
project is keeping all the amazing, productive, and resourceful =
developers in the world away, and if we leave with a bang, the project =
will immediately be rebooted in a way that is so much better than it has =
ever been. Somehow I'm skeptical.</div><div><br></div><div>So my current =
thinking is to improve and modernize the development infrastructure as =
much as I can, and maybe that will eventually attract more sane =
contributors to share the work with.&nbsp;If enough work is shared, =
there will be some real development going on, and discussions might be a =
good place to have err... discussions about it. At least upgrading the =
infrastructure and fixing bugs does not hurt the project in my =
opinion.</div><br><blockquote type=3D"cite"><div><div><blockquote =
type=3D"cite">Unfortunately, the authorship of the posts cannot be =
transferred.<br><br></blockquote>yeah ...<br><br>i wonder whether you =
could automatically set the watchers on issues<br>based on inferred =
participants, though? filtering by mentions would also<br>work, but only =
for the old issues, while new ones won't necessarily have<br>them. being =
able to filter by "watcher:..." would catch =
both.<br></div></div></blockquote><div><br></div><div>It is not possible =
to add watchers to issues using the API. However, GitHub will consider =
you a member of a conversation if you're mentioned in the issue and/or a =
comment, and will send you updates if you haven't disabled it in your =
profile. So I'm translating Trac usernames into mentions of GitHub =
handles where I can. I tried that in this =
issue:</div><div><br></div><div><a =
href=3D"https://github.com/MidnightCommander/mc-test-1/issues/28">https://=
github.com/MidnightCommander/mc-test-1/issues/28</a></div><div><br></div><=
div>I hope you've been notified. If not, I'm afraid there's nothing we =
can do.</div><br><blockquote type=3D"cite"><div><div><br><blockquote =
type=3D"cite">* Component (labels)<br> - adm: "area: =
adm"<br><br></blockquote>maybe put it in a separate repo instead? =
depends on whether you want to<br>create a separate repo for issues or =
want to attach them to the main<br>repo (i'd go with the =
latter).<br></div></div></blockquote><div><br></div><div>I want to have =
the same repository for code and issues, so that ticket references in =
the code can be linked to the issues, and commit references in the =
issues can be linked to the code. Unfortunately, this means we'll have =
to swap repositories, but I'm afraid there's no way around =
it.</div><div><br></div><div>I would rather keep tasks in the same =
repository for now. We can see if we can split things up later. I'd =
rather not start splitting things too much. And I think so far it has =
been a pretty small part of the tickets.</div><br><blockquote =
type=3D"cite"><div><div><br><blockquote type=3D"cite"> - translates: =
"area: i18n"<br> - locale: "area: i18n"<br> - translations: "area: =
i18n"<br><br></blockquote>pedantically, translations are l10n.<br>from =
experience i can say that users get this almost always wrong, =
but<br>assigning components is mostly a maintainer thing in mc =
anyway.<br></div></div></blockquote><div><br></div><div>That is correct, =
but this component has received tickets for both translation (l10n) and =
internationalization (i18n). I don't think "area: i18n &amp; l10n" looks =
much better and makes it clearer. Is it better now or =
not?</div><div><br></div><div><a =
href=3D"https://github.com/MidnightCommander/mc-test-1/issues">https://git=
hub.com/MidnightCommander/mc-test-1/issues</a></div><br><blockquote =
type=3D"cite"><div><div><br><blockquote type=3D"cite">* Resolution =
(partly labels, partly status)<br><br></blockquote>a bit of a mess, but =
i wouldn't know how to fix it.<br>i know that issue types can be =
configured at the organization level, but<br>i have no idea what =
else.</div></div></blockquote><br></div><div>Yes, I agree that this is =
suboptimal. Unfortunately, there are only built-in resolutions and you =
can't change them. Also, you get the resolution "fixed" on import =
whether you want it or not. I guess we'll have to live with the =
"worksfome" and "invalid" =
labels.</div><div><br></div><div><br></div><br></body></html>=

--Apple-Mail=_C18F4563-E254-46E9-B3EA-22B545FEDEF2--

--===============9054690046723127224==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
mc-devel mailing list
mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org
https://lists.midnight-commander.org/mailman/listinfo/mc-devel

--===============9054690046723127224==--