I suppose it would be better to make another release before 4.0, let's say 3.1.
It will include every change since last release + preparations for next major release (mostly internal stuff to ease contribution and repo management) - markdown linter and formatter, typos, old issues and PRs, some guidelines for local development, CI and pre-commit checks.

Another important question is formats of provided information. Are you sure that the project need cli version? And so on

Yes, let's develop a plan for the 3.1 release. As for the pre-commit checks, we should have a spell checker for non-code blocks in README.md. Many of the fixes we see involve spelling corrections.

Long run, what'd also be nice to have is a GitHub action that could run the snippets and verify the output, I've not thought about how it'll work, but it's something that could be useful.

As for the formats we need to keep, I agree we need to consolidate a bit. We can drop cli support, it isn't convenient to read anyway. We can just stick to Google colab notebooks (1 for each translation). Interactive web version and CLI versions can be dropped. I'd like to introduce a pdf version for those reading offline, this has been a frequent ask and long overdue.

Cool, then I'll create issues and you will add release milestone or label for them

• The entire pypi directory
• There might be a few scripts in irrelevant directory that we can delete, but you can leave it to me. We can delete after we know we aren't going to use any of that stuff.

Hey @nifadyev , Sorry it got missed thanks for the reminder. Here are my thoughts;

• We don't need stale action to automatically close the issues, rather it should be our job to keep closing them. Ideally, we should be tagging the issues, and depending on the tag we should have timelines to close them. For example, if the tag is bug or incorrect explanation then the action should remind us if the issue has been open for more than 15 days. If an issue is untagged for let's say 15 days, then action should remind us to tag it. If the issue is tagged as new snippet then we have to wait till the next release to get it out, in that case we have to keep it open. I hope I'm able convey where I'm getting with this

• Yeah we should close existing issues which aren't going to end up as examples.

• Agreed

• Yes monthly report is good

• It's a personal project and it helps me give credibitlity for the freelancing work I do, so for that reason I want to not move towards an organisation, as it'd make it difficult to get new work and sustain financially. Delegation of responsibilities can still be performed, people can comment on issues, review PRs, etc. It's just that my manual involvement would be needed (labeling issues, merging PRs, etc), which I'm more than happy doing.

• Agree with the changelogs

• Agree with the contributing guide. Regarding irrelevant, it's irrelevant from reader's perspective but some of the code is relevant from our purpose. So I think we need to do two things there, the code that is obsolete, we can delete it. The other code we can still keep it and not call irrelevant but something else like internal

Hey @satwikkansal , thank you for a reply.
I will start making issues for all points discussed above with more details, and wait for your approval to proceed with them.
Meanwhile, it'd be awesome to the issues (1 2 3 4 5 6 7 8 9 10 11 12 13 14) and PR (except 1 2 3)

Sure, will do that over next few days 👍

Hey @satwikkansal , updated the list of issues to delete. Most issues are new snippets and they shall not be included in upcoming small patch release. They will be a part of new major release

I closed the issues you linked, and most inactive PRs. Most of the remaining issues are actually snippets that we may intend to include in new major release so we can keep them open, and close them after the release. Thanks for going over them and leaving your comments @nifadyev 🙏