Status of the project

[torik42]

This project is great and together with LanguageTool the best LaTeX spellchecker I have seen so far. However, there are some reasonable PRs (and more issues) which haven’t been touched for more than a year.

Do you plan to continue working on this project?

I understand that this is a hobby side project and the time you put in is limited. If that helps, I would be willing to invest some time to review and improve open PRs so that you can merge them more easily.

[JulianGoeltz]

I wholeheartedly agree, YaLafi is amazing.

Given that there has not been any activity by @matze-dd for some time, is there a way for you to perhaps adopt the project, so the open issues/PRs can be merged to an up-to-date state?

[torik42]

I would like to find a solution together with @matze-dd. He started the whole project as a hobby (see his comment) and put a lot of effort into it. As such, I totally understand, that there are times without progress. And even merging pull requests can take a serious amount of time, because they don’t meet all requirements and need testing.

Before adopting the project and merging open PRs in a different fork, I would wait for an answer to this issue and try to contact @matze-dd directly. Only as a last resort, I would consider maintaining a different fork, which also comes with major drawbacks.

[matze-dd]

Hi folks,

thank you for the positive feedback. I'm really happy that the project is useful for you. I agree that some reasonable and substantial requests for updates have accumulated.

Unfortunately, I cannot continue to develop the software. So, if someone would volunteer, there are at least three options, and quite probably we can find others, too.

• You could create a fork and continue there. As @torik42 mentioned, this might raise issues. In this case, we maybe even could keep the project name and deactivate the current repository later on (leaving just a link to the new one)?
• Perhaps, it is possible to change the principal maintainer of the current project? The drawback would be that it then continues to run under the @matze-dd branch.
• See here for transferring the current repository. This would be fine, too.

In all cases, we would also need to find a solution for updates of the PyPI repository.

Best whishes
Matthias

PS. Be warned that until now this has been a hobbyist's work. So, you will certainly find many places with dirty tricks, inappropriate program / data structure or insufficient documentation.

[torik42]

Great to hear from you, Matthias!

In case you really intend to not continue development at all and are willing to give YaLafi away, I think the cleanest way is to transfer the repository. This would allow the new maintainer to access old and open issues/PRs/discussions. To my impression, this would fit quite well with moving also the PyPI repository to the new maintainer, if that is your intention. I will read up on what to do for these steps in the next days.

I would also understand, if you feel better with archiving this repository and let the new maintainer work in a fork. Then we still need a solution for the PyPI repository. In this case one could abandon YaLafi and start with a new one. For the end user and new maintainer this seems more complicated to me.

If you still want to stay the owner of the project, you could add a second maintainer, who can merge PRs and manage the repository.

I still volunteer to maintain the project (at least for the next few years). In that case it will stay “hobbyist’s work”. In case someone else would maintain the project as well, or wants to do it jointly, please join the discussion. (Mentioning recent PR authors here: @rubdos, @rpls, @mstmob, @symphorien, @Konfekt.) I would need some help especially for changes in the vim part, because I don’t use vim myself and there are no automated tests (to my knowledge) for that.

Last but not least, let me thank you again for developing YaLafi, it works very well for spell checking LaTeX documents and produces less false negatives and less false positives than other options I have tried.

[Konfekt]

Hello @torik42, I could help with the Vim part. @lervag 's https://github.com/lervag/vimtex/blob/master/compiler/vlty.vim implements the changes proposed here and seemingly works fine.

[matze-dd]

Yes, @torik42, we are in accord. A clear cut is the best we can do. Thank you for initiating this thread. As you point it out, it's a little pity to give the project away, but I really cannot invest the time, anymore. I think, at least the filter core 'yalafi' is in reasonable shape, whereas the interface software 'yalafi.shell' would benefit from some tidy up.

In case you really intend to not continue development at all and are willing to give YaLafi away, I think the cleanest way is to transfer the repository. This would allow the new maintainer to access old and open issues/PRs/discussions.

Under the 'matze-dd' branch, I would create an archive copy of the current repo. After transferring the repo to the new maintainer, I'd start a new 'matze-dd/YaLafi' with just a README that links to the maintained and frozen project versions.

To my impression, this would fit quite well with moving also the PyPI repository to the new maintainer, if that is your intention. I will read up on what to do for these steps in the next days.

That's nice. We then could change ownership of the Python package, too.

I would need some help especially for changes in the vim part, because I don’t use vim myself and there are no automated tests (to my knowledge) for that.

This is true. But the Vim interfaces only rely on the format of the proofreading report in text form, as well on recognition of some command-line arguments. For both things, there are tests, if I remember right. In order to ease maintanance, I could write a list of the critical points to be observed. I would also inform the maintainer of VimTeX, as this project contains an interface ('vlty') to LanguageTool / YaLafi.

I still volunteer to maintain the project (at least for the next few years).

This would be really GREAT. Just let's wait some time if someone else is interested.

Last but not least, let me thank you again for developing YaLafi, it works very well for spell checking LaTeX documents and produces less false negatives and less false positives than other options I have tried.

Thank you for the kind words. I've made some effort to let the filter work well with my own LaTeX documents, and this fortunately seems to transfer to others.

PS. Cross-post. Thanks, @Konfekt!

[JulianGoeltz]

Just in case you are not aware, I want to mention organizations in GitHub. As far as I understand, this idea fits quite well: you @matze-dd can remain part of the organization together with other people. And if you transfer the repository to an organization, GitHub will link automatically from your repository to the organization's one (that's at least my experience).

Regarding volunteering, I've only added features locally (without test coverage), so I would need to look up the tests but if @torik42 wants I can try to be of help as well.

[torik42]

I am happy that this discussion becomes so fruitful. Let me also add some comments:

In case you really intend to not continue development at all and are willing to give YaLafi away, I think the cleanest way is to transfer the repository. This would allow the new maintainer to access old and open issues/PRs/discussions.

Under the 'matze-dd' branch, I would create an archive copy of the current repo. After transferring the repo to the new maintainer, I'd start a new 'matze-dd/YaLafi' with just a README that links to the maintained and frozen project versions.

According to the GitHub Docs, when you transfer a repository, all forks remain valid and the matze-dd/YaLafi remote would automatically be linked to the new maintainer's repository. Nevertheless, changing the remotes to the new urls is recommended. I guess, this will not work, when you set up a new repository with just a readme.

Also, if you transfer the repository, what do you mean with frozen project version. As far as I understand, this will remove the repo from your account. Which is also what I see as a main drawback for you, because it will remove quite a lot of work from your list of repositories. That could be handled by pinning the transferred repo or creating a fork of it.

Major drawback for the new maintainer is, that one cannot have a fork when getting the repo transferred. And I am not sure, what happens to the open PRs if the new maintainer removes his old fork.

Just in case you are not aware, I want to mention organizations in GitHub. As far as I understand, this idea fits quite well: you @matze-dd can remain part of the organization together with other people. And if you transfer the repository to an organization, GitHub will link automatically from your repository to the organization's one (that's at least my experience).

Yes, I thought about that as well. I would prefer that, if @matze-dd wants to be involved in the future (which does not seem to be the case). An organization seems to be overkill for one person managing one repository. It would remove the problem with the current fork of the new maintainer though.

I would need some help especially for changes in the vim part, because I don’t use vim myself and there are no automated tests (to my knowledge) for that.

This is true. But the Vim interfaces only rely on the format of the proofreading report in text form, as well on recognition of some command-line arguments. For both things, there are tests, if I remember right. In order to ease maintanance, I could write a list of the critical points to be observed. I would also inform the maintainer of VimTeX, as this project contains an interface ('vlty') to LanguageTool / YaLafi.

That would be great, but does not need to be done first. According to the readme “A copy of the corresponding Vim compiler script is editors/vlty.vim.” So we are safe to copy the changes from VimTeX? Will see whether that is exactly, what @Konfekt did in the PR.

@JulianGoeltz:

Regarding volunteering, I've only added features locally (without test coverage), so I would need to look up the tests but if @torik42 wants I can try to be of help as well.

More improvements are very welcome! After the transfer (if I end up as the new maintainer) I would go through the open Issues/PRs and add some more documentation about testing locally, writing tests, etc. (current information is in CONTRIBUTING.md).

[matze-dd]

Thank you for thinking all this over.

According to the GitHub Docs, ... Nevertheless, changing the remotes to the new urls is recommended. I guess, this will not work, when you set up a new repository with just a readme.

Locally, I'm just using plain git. In case I wanted to contribute again, I would create a GitHub fork from the transferred repo, but under a modified name (chosen directly when forking).

Also, if you transfer the repository, what do you mean with frozen project version.

As described here, one can create a repo copy using git operations. In my understanding, the additional repo will only contain the directory structure with program and other files, but no additional GitHub data for PRs etc. This then would be the "frozen" version, for instance 'matze-dd/YaLafi-2022-09-01'.

As far as I understand, this will remove the repo from your account. Which is also what I see as a main drawback for you, because it will remove quite a lot of work from your list of repositories. That could be handled by pinning the transferred repo or creating a fork of it.

This would be the purpose of the new repo 'matze-dd/YaLafi' with just a readme after transferring. (I still think that starting the new repo should be possible, as the transferred one completely vanished from my user path.) The readme with links to frozen and transferred versions would serve as entry point for links from outside of GitHub and hard-coded URLs. As mentioned above, creating an additional fork under a modified name should be possible. Pinning is a good idea, too, thanks! Will have a look at it.

Major drawback for the new maintainer is, that one cannot have a fork when getting the repo transferred. And I am not sure, what happens to the open PRs if the new maintainer removes his old fork.

Yes. Even renaming the fork before transferring the repo won't help, if the documentation is correct. As an emergency exit: could the new maintainer create an auxiliary account (assuming that a second mail address suffices) and transfer the fork to the new user? Perhaps, one could keep the new user until all PRs / merges from the fork into the transferred YaLafi repo have been finished. Afterwards, the fork and the additional account could be removed?

An organization seems to be overkill for one person managing one repository. It would remove the problem with the current fork of the new maintainer though.

If anything else fails, we should use the organization option. I agree that somehow keeping the current fork under the new maintainer's access is vital.

In any case, I'd propose to try the whole process with a toy repo.

That would be great, but does not need to be done first. According to the readme “A copy of the corresponding Vim compiler script is editors/vlty.vim.” So we are safe to copy the changes from VimTeX? Will see whether that is exactly, what @Konfekt did in the PR.

Yes. Lervag, the VimTeX author, sometimes makes small changes mainly related to VimTeX improvements. So, he and the users are testing his 'vlty.vim'. One could add to our readme that the local copy of this file might be an outdated version.

[matze-dd]

Just in case you are not aware, I want to mention organizations in GitHub. As far as I understand, this idea fits quite well: you @matze-dd can remain part of the organization together with other people. And if you transfer the repository to an organization, GitHub will link automatically from your repository to the organization's one (that's at least my experience).

Thank you for the hint, @JulianGoeltz! Somewhere else, @torik42 estimated that this might be an overkill, and I agree. After all, this is a rather small software only useful when plugged together with other, more mighty tools. So, one maintainer should suffice.

If, let's say, @torik42 does the further development work, then he shall earn all the merits. (Vice versa, if something goes wrong, then it has to go on his name ;)

But thanks again, it's sensible to consider all options (see also the problem with the fork in the above posts). If, in the future, I decided to contribute again, then there should be no problem in finding a way.

[torik42]

Locally, I'm just using plain git. In case I wanted to contribute again, I would create a GitHub fork from the transferred repo, but under a modified name (chosen directly when forking).

As described here, one can create a repo copy using git operations. In my understanding, the additional repo will only contain the directory structure with program and other files, but no additional GitHub data for PRs etc. This then would be the "frozen" version, for instance 'matze-dd/YaLafi-2022-09-01'.

I see, that sounds like a good solution. You should even be able to do that before the transfer.

As far as I understand, this will remove the repo from your account. Which is also what I see as a main drawback for you, because it will remove quite a lot of work from your list of repositories. That could be handled by pinning the transferred repo or creating a fork of it.

This would be the purpose of the new repo 'matze-dd/YaLafi' with just a readme after transferring. (I still think that starting the new repo should be possible, as the transferred one completely vanished from my user path.) The readme with links to frozen and transferred versions would serve as entry point for links from outside of GitHub and hard-coded URLs. As mentioned above, creating an additional fork under a modified name should be possible. Pinning is a good idea, too, thanks! Will have a look at it.

What I meant before is the following: If you transfer the repo (and don’t create a new one under the same name), remotes and hopefully other links to github.com/matze-dd/YaLafi would be redirected (about the latter I am not so sure). Setting up the new repo matze-dd/YaLafi would be more verbose (which I like), but the automatic redirecting will probably not work?

Major drawback for the new maintainer is, that one cannot have a fork when getting the repo transferred. And I am not sure, what happens to the open PRs if the new maintainer removes his old fork.

Yes. Even renaming the fork before transferring the repo won't help, if the documentation is correct. As an emergency exit: could the new maintainer create an auxiliary account (assuming that a second mail address suffices) and transfer the fork to the new user? Perhaps, one could keep the new user until all PRs / merges from the fork into the transferred YaLafi repo have been finished. Afterwards, the fork and the additional account could be removed?

Before doing that, I would probably go the organization route. My current plan was to remove my fork (maybe push it to a different repo as backup) and then push the branches again to the transferred repo. With some luck, even my old PRs would be usable again. (We could also test that.)

If, let's say, @torik42 does the further development work, then he shall earn all the merits. (Vice versa, if something goes wrong, then it has to go on his name ;)

I wouldn’t see any problem with that. It would be good anyway, to put you as the author and the new maintainer as maintainer in the readme. Just the url would be YaLafi/YaLafi instead of new-maintainer/YaLafi.

In any case, I'd propose to try the whole process with a toy repo.

Very good idea!

[matze-dd]

I wouldn’t see any problem with that. It would be good anyway, to put you as the author and the new maintainer as maintainer in the readme. Just the url would be YaLafi/YaLafi instead of new-maintainer/YaLafi.

As this is a small project, I'd prefer 'new-maintanier/YaLafi'. If we have to go the organization path, 'YaLafi/YaLafi' probably will fit better.
In my opinion, it is sufficient to place a remark in the intro section of readme that the software has been developed by me till version x.x. If we do not take the organization option, then the maintainer seems to be obvious, but of course could be named for clarity. BTW, I have to draft a new version including "ongoing work" from history.md.

What I meant before is the following: If you transfer the repo (and don’t create a new one under the same name), remotes and hopefully other links to github.com/matze-dd/YaLafi would be redirected (about the latter I am not so sure).

What exactly do you mean by "remotes"? Quite unsure about all this, we have to try. I'd expect that internal references, for instance between repos, forks, RPs and so on, are kept due to internal IDs that do not depend on repo owner or location. But I'd be surprised to see updated links in text files (if you mean these).

Setting up the new repo matze-dd/YaLafi would be more verbose (which I like), but the automatic redirecting will probably not work?

Unsure if I understand you correctly. Do you think that the URL 'github.com/matze-dd/YaLafi' would automatically lead a browser to the transferred repo, if I do not start a new repo after transferring?

Very good idea!

Here is an initial plan for testing. What do you think?

1. matze-dd: create repo matze-dd/Toy with a readme, a text file including a hard URL link, a program file
2. matze-dd: create "frozen copy" of the repo
3. torik42: fork, make change, raise a PR
4. torik42: do things to save changes from fork, for example:

Before doing that, I would probably go the organization route. My current plan was to remove my fork (maybe push it to a different repo as backup) and then push the branches again to the transferred repo. With some luck, even my old PRs would be usable again. (We could also test that.)

5. torik42: remove fork
   --> PR vanishes from repo
6. matze-dd: create again a repo copy with git commands: the new repo should only contain the "raw directory", no PR etc.
   --> OK: no PRs etc are coppied, only branches
7. matze-dd: transfer repo Toy to torik42
8. torik42: test if PR from "saved" fork can be merged
9. matze-dd: test of "automatic redirection" on 'github.com/matze-dd/YaLafi', check if link in text file has been updated
   --> github.com/matze-dd/Toy redirects browser to torik42/Toy
   --> absolute links in text files are not updated
10. matze-dd: start new repo Toy with readme containing links to frozen and transferred versions

[torik42]

BTW, I have to draft a new version including "ongoing work" from history.md.

I am not quite sure, whether I get that. Do you want to publish the current changes to PyPI before the transfer? (I am happy with that.)

What exactly do you mean by "remotes"?

When people pull the repo, they set up remotes, e.g. matze-dd/YaLafi, as well as their own fork someone/YaLafi, this way they can fetch new changes from the original repo. According to the docs, this link is redirected, i.e. pulling from matze-dd/YaLafi after a transition will actually pull from new-maintainer/YaLafi. They nevertheless recommend to change the remotes git remote set-url origin new_url (if the remote is named origin).

Quite unsure about all this, we have to try. I'd expect that internal references, for instance between repos, forks, RPs and so on, are kept due to internal IDs that do not depend on repo owner or location. But I'd be surprised to see updated links in text files (if you mean these).

Exactly, I expect, that https://github.com/matze-dd/YaLafi would be redirected to https://github.com/new-maintainer/YaLafi. That’s also the reason, why I say that this redirection could be broken, if you make a new repo with the same name. It would be more verbose, if you create a new repo, because anyone visiting https://github.com/matze-dd/YaLafi would see your readme with the link to the transferred repo. I don’t expect any files to be changed.

Here is an initial plan for testing. What do you think?

Very good. Start whenever you want. You could consider making it in a private repo, there are some differences between transferring private and public repos though.

[matze-dd]

OK, have created repo matze-dd/Toy and a copy Toy-131 (version to be archived after transfer of Toy).

Additionally, I have placed the README from PyPI under a new directory pypi/, and have started the description of Vim interfaces under editors/VIM.md. Would the form as for "Plain Vim" suffice?

[torik42]

I […] have started the description of Vim interfaces under editors/VIM.md. Would the form as for "Plain Vim" suffice?

Looks good. I think that’s enough. Maybe I’ll at least try out all variants to see how they work.

[torik42]

Created a fork, a PR, an issue and a backup and deleted my fork. The PR was closed, but is still there. We’ll see what happens after the transfer.

[matze-dd]

Made a second repo copy, again to Toy-131: my PR and our issues haven't been copied, as expected.

Requested a transfer of Toy to you. I assume that you get an info and have to accept.

Crossing fingers that the PR somehow reappears ...

[torik42]

During the test run, it turned out that PRs get closed, when a fork is deleted and cannot be reopened after the transfer.

I suggest the following procedure:

Steps before transfer: matze-dd

• Make a new version and publish to PyPI.
• Create a frozen copy under a different name like YaLafi v1.3.1.

Steps before transfer: torik42

• Make a backup of all branches in the fork.
• Remember own open PRs: 196 (draft), 198, 199, 204.
• Delete the fork from GitHub.
• Create account on PyPI

Transfer

• matze-dd transfers the GitHub repo to torik42
• matze-dd transfers the PyPI ownership

Steps after transfer: matze-dd

• Maybe setup new repo under matze-dd/YaLafi with links to the new repo and the v1.3.1 archive
• Maybe archive the v1.3.1 repo on GitHub? (Then nobody can raise a PR)

Steps after transfer: torik42

• Add note about changed maintainers and acknowledge matze-dd’s development.
• Add links to the frozen repo (and the new matze-dd/YaLafi if created)
• Add note how to set up new remote.
• Make new PRs for the closed ones referencing the old discussion.
• Test publish on test.pypi.org.
• continue development

Do you have any comments or additions? I would then update this post accordingly.

[matze-dd]

Thank you, this looks good. After you have created a PyPI account, I can add you as collaborator and delete me as collaborator. Then, you should "own" the package on PyPI.

I'll create repo Yalafi-1.3.1. Please give me a ring, when you are ready for the repo transfer.

[torik42]

All pre-transfer steps done.

[matze-dd]

OK, transfer finished!

I've taken your suggestion and pinned the repo, and automatic forwarding works. So, it is not necessary to start a new repo with a readme containg links to your and my "frozen" version. Some day, I will just un-archive the latter one and add a short remark to the readme's top.

For some reason, I cannot remove myself as owner of the PyPI package. According to a comment in the Web, you should be able, though. Just feel free to do that.

I thank you sincerely for taking over the project. Good luck with the further development!

[torik42]

Thank you for the kind words and developing YaLafi.

I will remove you as maintainer after publishing the next version. For the author field (in setup.py and thus on PyPI) I suggest leaving your name and appending torik42.

[torik42]

Closing after publishing a new version to PyPI.