Re: Need help with GitHub Issues migration

--===============0084536672783619692==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D484781C-F77F-4026-9EE3-B07D160FEC4E"


--Apple-Mail=_D484781C-F77F-4026-9EE3-B07D160FEC4E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 24. Feb 2025, at 12:49, Oswald Buddenhagen via mc-devel =
<mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org> wrote:
>=20
> On Mon, Feb 24, 2025 at 09:39:16AM +0100, Yury V. Zaytsev wrote:
>> 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. [...]
>>=20
> the underlying assumption of what you wrote is that the better
> accessibility of the medium will decrease the signal-to-noise ratio.
> i don't think this would be the case to a significant degree. mc is =
too
> niche for that.

Hmmm, I don't think that's what I meant to say. The point I was trying =
to make is that I think active organization and moderation will lead to =
a better signal-to-noise ratio, which I think is desirable. Conversely, =
just opening Discussions without doing anything to organize them well =
and actively moderating them will potentially lead to another place in =
the repository where I don't want to be at all, but it will be even =
harder to avoid being right next to issues and code.

> but suppose it would, then i wouldn't mind being the one who flames =
away
> the flamers. :'-D

Speaking of which, would you be interested in issue admin privileges for =
starters? I think you had them on Trac, if I'm not mistaken.=20

> as you noted, the list has almost no traffic, and i wouldn't expect =
that
> to change much. that makes the question mostly irrelevant in the first
> place. otoh, one can view that as a reason to consolidate further, to
> not have spread out resources for something that doesn't matter all =
that
> much.

As I said, the lists in their current state don't require any resources =
at the moment... but I'll take a look at the Discussions after the =
migration to Issues. Thanks for the suggestion. What I'm more concerned =
about is the website and wiki. That's something I'd have to sort out =
before we can get rid of Trac, so it's a higher priority for me at the =
moment.

>> It is not possible to add watchers to issues using the API.
>>=20
> too bad.

Well, it's a platform issue. They don't allow it in the same way that =
they don't allow you to keep real reporters' identities. All I can do is =
mention. They just don't want you to be able to do things for other =
members or on behalf of other members on their platform that they are =
responsible for. If you're self-hosting, then you can force-create user =
accounts and set them up as reporters of issues, and that's your thing.

>> 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.
>>=20
> are you sure? it will definitely send a notification for the mention
> itself, but if the recipient doesn't respond (which would make them a
> participant and thus a watcher by default), would they keep receiving
> followups?

That's how I read their documentation, specifically "Had your username =
@mentioned", but it seems I'm wrong.

=
https://docs.github.com/en/account-and-profile/managing-subscriptions-and-=
notifications-on-github/setting-up-notifications/about-notifications#defau=
lt-subscriptions


>> https://github.com/MidnightCommander/mc-test-1/issues/28
>>=20
>> I hope you've been notified. If not, I'm afraid there's nothing we =
can
>> do.
>>=20
> it didn't work, but that might also be because the repo is archived.
>=20
> anyway, i was aiming specifically at filtering, "my issues" style.

Hmmm, searching for "reporter:ossi" seems to work perfectly for this use =
case. I hope this solves your problem.=20

=
https://github.com/MidnightCommander/mc-test-1/issues?q=3D%22reporter%3Aos=
si%22%20

Of course, this will not work for newly reported issues, unless we do =
some dark action magic to put the reporter username in the issue body in =
an invisible way.

There seems to be an action for that:

https://github.com/marketplace/actions/update-issue-body

Not sure if it's worth the effort though. You can just as easily search =
for "reporter:ossi or author:ossi".

>> Unfortunately, this means we'll have to swap repositories, but I'm
>> afraid there's no way around it.
>>=20
> i'm not sure i get what you're saying here. that you can't import the
> issues into the pre-existing repo?

Yes, that's what I mean. The issue numbers in the current repository are =
busted because on GitHub (historically, unlike GitLab) they share the =
same number space with PRs, and the latter can't be disabled. So issue =
numbers up to about 300 are taken. Either I have to discard those Trac =
tickets, or I have to break the numbering. Or I can take an empty =
repository and fill it with Trac stuff, but then the old PRs will not be =
visible there.

> that would indeed suck a bit, as there were a few worthwhile
> discussions in a few PRs. it should be possible to export the data,
> combine it, and then import it, no?

For issues, I guess that's possible, but we don't have issues in the old =
repository. We only have PRs. And the discussions are mostly attached to =
the code. I see no useful way to export and re-import that information =
into the new repository. I would just keep the old one, rename it to =
"mc-old", and archive it. You can always check the PRs there if you =
really need to.

>> 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?
>>=20
> it's more correct, but it looks noisy. maybe "locales" would be a =
better
> keyword.

I wasn't sure about locales, but you may be right. I have updated it =
now. I hope it's okay now.

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

>>>> * Attachment uploads via the API are not supported and will be
>>>> hosted in a separate repository
>=20
> you mean like that? =
https://github.com/orgs/community/discussions/46951#discussioncomment-6394=
596

Yes, correct. That is exactly what I did. I think that's acceptable. =
Here is an example:

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

> maybe https://github.com/j178/github-s3 would be an alternative?

But what is the advantage compared to the above solution? I can only see =
disadvantages (loss of control).


--Apple-Mail=_D484781C-F77F-4026-9EE3-B07D160FEC4E
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 24. Feb =
2025, at 12:49, Oswald Buddenhagen via mc-devel =
&lt;mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>On Mon, Feb 24, 2025 at =
09:39:16AM +0100, Yury V. Zaytsev wrote:<br><blockquote =
type=3D"cite">TLDR; if you have a plan and want to volunteer to set up =
and actively<br>participate in a moderated community with discussions, =
then let's<br>discuss the plan and implement it after the move. =
[...]<br><br></blockquote>the underlying assumption of what you wrote is =
that the better<br>accessibility of the medium will decrease the =
signal-to-noise ratio.<br>i don't think this would be the case to a =
significant degree. mc is too<br>niche for =
that.<br></div></div></blockquote><div><br></div><div>Hmmm, I don't =
think that's what I meant to say. The point I was trying to make is that =
I think active organization and moderation will lead to a better =
signal-to-noise ratio, which I think is desirable. Conversely, just =
opening Discussions without doing anything to organize them well and =
actively moderating them will potentially lead to another place in the =
repository where I don't want to be at all, but it will be even harder =
to avoid being right next to issues and code.</div><br><blockquote =
type=3D"cite"><div><div>but suppose it would, then i wouldn't mind being =
the one who flames away<br>the flamers. =
:'-D<br></div></div></blockquote><br><div>Speaking of which, would you =
be interested in issue admin privileges for starters? I think you had =
them on Trac, if I'm not mistaken.&nbsp;</div><br><blockquote =
type=3D"cite"><div><div>as you noted, the list has almost no traffic, =
and i wouldn't expect that<br>to change much. that makes the question =
mostly irrelevant in the first<br>place. otoh, one can view that as a =
reason to consolidate further, to<br>not have spread out resources for =
something that doesn't matter all =
that<br>much.<br></div></div></blockquote><div><br></div><div>As I said, =
the lists in their current state don't require any resources at the =
moment... but I'll take a look at the Discussions after the migration to =
Issues. Thanks for the suggestion. What I'm more concerned about is the =
website and wiki. That's something I'd have to sort out before we can =
get rid of Trac, so it's a higher priority for me at the =
moment.</div><br><blockquote type=3D"cite"><div><div><blockquote =
type=3D"cite">It is not possible to add watchers to issues using the =
API.<br><br></blockquote>too =
bad.<br></div></div></blockquote><div><br></div><div>Well, it's a =
platform issue. They don't allow it in the same way that they don't =
allow you to keep real reporters' identities. All I can do is mention. =
They just don't want you to be able to do things for other members or on =
behalf of other members on their platform that they are responsible for. =
If you're self-hosting, then you can force-create user accounts and set =
them up as reporters of issues, and that's your =
thing.</div><div><br></div><blockquote type=3D"cite"><div><div><blockquote=
 type=3D"cite">GitHub will consider you a member of a conversation if =
you're mentioned<br>in the issue and/or a comment, and will send you =
updates if you haven't<br>disabled it in your =
profile.<br><br></blockquote>are you sure? it will definitely send a =
notification for the mention<br>itself, but if the recipient doesn't =
respond (which would make them a<br>participant and thus a watcher by =
default), would they keep =
receiving<br>followups?<br></div></div></blockquote><div><br></div><div>Th=
at's how I read their documentation, specifically "Had your username =
@mentioned", but it seems I'm wrong.</div><div><br></div><div><a =
href=3D"https://docs.github.com/en/account-and-profile/managing-subscripti=
ons-and-notifications-on-github/setting-up-notifications/about-notificatio=
ns#default-subscriptions">https://docs.github.com/en/account-and-profile/m=
anaging-subscriptions-and-notifications-on-github/setting-up-notifications=
/about-notifications#default-subscriptions</a></div><div><br></div><br><bl=
ockquote type=3D"cite"><div><div><blockquote =
type=3D"cite">https://github.com/MidnightCommander/mc-test-1/issues/28<br>=
<br>I hope you've been notified. If not, I'm afraid there's nothing we =
can<br>do.<br><br></blockquote>it didn't work, but that might also be =
because the repo is archived.<br><br>anyway, i was aiming specifically =
at filtering, "my issues" =
style.<br></div></div></blockquote><div><br></div><div>Hmmm, searching =
for "reporter:ossi" seems to work perfectly for this use case. I hope =
this solves your =
problem.&nbsp;</div><div><br></div><div>https://github.com/MidnightCommand=
er/mc-test-1/issues?q=3D%22reporter%3Aossi%22%20</div><div><br></div><div>=
Of course, this will not work for newly reported issues, unless we do =
some dark action magic to put the reporter username in the issue body in =
an invisible way.</div><div><br></div><div>There seems to be an action =
for =
that:</div><div><br></div><div>https://github.com/marketplace/actions/upda=
te-issue-body</div><div><br></div><div>Not sure if it's worth the effort =
though. You can just as easily search for "reporter:ossi or =
author:ossi".</div></div><div><div><br></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite">Unfortunately, this =
means we'll have to swap repositories, but I'm<br>afraid there's no way =
around it.<br><br></blockquote>i'm not sure i get what you're saying =
here. that you can't import the<br>issues into the pre-existing repo? =
</div></div></blockquote><div><br></div><div>Yes, that's what I mean. =
The issue numbers in the current repository are busted because on GitHub =
(historically, unlike GitLab) they share the same number space with PRs, =
and the latter can't be disabled. So issue numbers up to about 300 are =
taken. Either I have to discard those Trac tickets, or I have to break =
the numbering. Or I can take an empty repository and fill it with Trac =
stuff, but then the old PRs will not be visible =
there.</div><br><blockquote type=3D"cite"><div><div>that would indeed =
suck a bit, as&nbsp;there were a few =
worthwhile</div></div></blockquote><blockquote =
type=3D"cite"><div><div>discussions in a few PRs. it should =
be&nbsp;possible to export the data,</div></div></blockquote><blockquote =
type=3D"cite"><div><div> combine it, and then import it, =
no?<br></div></div></blockquote><div><br></div><div>For issues, I guess =
that's possible, but we don't have issues in the old repository. We only =
have PRs. And the discussions are mostly attached to the code. I see no =
useful way to export and re-import that information into the new =
repository. I would just keep the old one, rename it to "mc-old", and =
archive it. You can always check the PRs there if you really need =
to.</div><br><blockquote type=3D"cite"><div><div><blockquote =
type=3D"cite">That is correct, but this component has received tickets =
for both<br>translation (l10n) and internationalization (i18n). I don't =
think<br>"area: i18n &amp; l10n" looks much better and makes it clearer. =
Is it<br>better now or not?<br><br></blockquote>it's more correct, but =
it looks noisy. maybe "locales" would be a =
better<br>keyword.<br></div></div></blockquote><br><div>I wasn't sure =
about locales, but you may be right. I have updated it now. I hope it's =
okay now.</div><div><br></div><div><a =
href=3D"https://github.com/MidnightCommander/mc-test-1/labels">https://git=
hub.com/MidnightCommander/mc-test-1/labels</a></div><br><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">* Attachment uploads via the API =
are not supported and will be<br>hosted in a separate =
repository<br></blockquote></blockquote></blockquote><br>you mean like =
that? =
https://github.com/orgs/community/discussions/46951#discussioncomment-6394=
596<br></blockquote><div><br></div><div>Yes, correct. That is exactly =
what I did. I think that's acceptable. Here is an =
example:</div><div><br></div><div><a =
href=3D"https://github.com/MidnightCommander/mc-test-1/issues/4631">https:=
//github.com/MidnightCommander/mc-test-1/issues/4631</a></div><br><blockqu=
ote type=3D"cite">maybe https://github.com/j178/github-s3 would be an =
alternative?<br></blockquote><br></div><div>But what is the advantage =
compared to the above solution? I can only see disadvantages (loss of =
control).</div><div><br></div></body></html>=

--Apple-Mail=_D484781C-F77F-4026-9EE3-B07D160FEC4E--

--===============0084536672783619692==
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

--===============0084536672783619692==--