Future of zk: looking for maintainers

[mickael-menu]

Hi,

Thank you all for your support with this project. Unfortunately I can't dedicate the time needed to maintain zk anymore.

If one or more people are willing to maintain it, I suggest we create a GitHub organization and transfer the four repositories:

• https://github.com/mickael-menu/zk
• https://github.com/mickael-menu/zk-nvim
• https://github.com/mickael-menu/zk-xcompile
• https://github.com/mickael-menu/zk-vscode

You would be co-admins of the organisation and full maintainers of the project.

Let me know if anyone feels up to the task.

[mickael-menu]

@mcDevnagh spontaneously created the organization zk-notes. I would be fine transfering the repos there if there's some kind of consensus.

Anyone has a better name for the organization?

[mcDevnagh]

I deleted the forks, so the zk-notes org is ready to receive the transfers.
I have the changes I made locally, and I'll make them PRs to the new repos once you transfer them

[tjex]

A real bummer to see you go! Although I'm fairly new to zk, I can very easily see how much time and energy you put into the project. By the way you were interacting with others in discussions and issues; always kind, thoughtful and in depth. Always so nice to have a maintainer with that energy.

And looking through the source code. So well commented and laid out.

Thanks so much for the work 🙏

I'm very interested to be involved. I can't say with any confidence that I have the necessary experience to cover everything. I'm just not that experienced yet. But that changes with time of course, and in the interim I can imagine myself helping to triage issues, write documentation and fix small bugs. It's also a project that I'm very invested in. I hold a lot of value to my Zettelkasten, and zk is finally the tool that hits the balance for what I want and need.

Is there some critical mass of new maintainers that would mean you would stay involved a little on the side lines? Or you're totally out?

Name iterations off the top of my head:

• zk-neo
• zk-org
• zkasten
• neo-zk

zk-notes does make for a fine umbrella name, but it does also sound like a name that could be used for an additional project down the line within the org.

[mickael-menu]

Thank you ❤️

I'll make sure to at least have some time to help new maintainers navigate the codebase and tooling. And maybe participate in the evolution discussions.

As for the name, I have a small preference for zk-org or zk-group which are the most general ones (zk, zkasten, zettelkasten are all already taken, but zettelk looks free).

[mcDevnagh]

zk-org works for me. Shall I rename zk-notes?

[mickael-menu]

I just did, transfered all the repos and also added @kabouzeid as co-owner, as he was the main author of the zk-nvim extension.

Let me know if you need anything from me!

[mcDevnagh]

First of all, thank you for your hard work! I've gone deep down the rabbit hole of note taking software, and zk is perfect for me. That is why I was quick to make an org and a fork, since I couldn't find a discussion like this when I noticed the archive status of the repo.

I am a full stack Software Engineer mostly using C# and MSSQL. I have done hobby projects using golang and sqlite, but this is no mere hobby project. I'd be more than happy to learn, though.

I'd gladly transfer ownership of the org, if a more established successor comes forward, but I'm willing to take up some responsibilty too, whether or not one does.

Also, I already made some changes to the code to get it working in the new org:

• https://github.com/zk-notes/zk/commit/063c20c7e6cf34ca32a3ba2e58a8bc8a499e88be pipelines were failing, and I found an existing bug with relative dates in the test suite
• https://github.com/zk-notes/zk/commit/5f537f4d2d384ad4c9c7ecfbceb97053801ee56c I changed the GitHub repo URLs everwhere (thank God for sed)

I have those changes on my local machine, so if you transfer over the repos, I can delete the new repos, then push up my changes

In case anyone is wondering, I renamed zk-nvim to zk.nvim since NeoVim plugin managers tend to save plugins in a directory of its name, without the name of the org/owner (so in this case zk-nvim, not mickael-menu/zk-nvim), so they don't play nicely with the multiple plugins named the same. See https://github.com/nvimtools/none-ls.nvim

[tjex]

awesome! Here to help 🫡

[mickael-menu]

Thanks Michael 🙏

I think with the repo transfer it should be fine with the previous name, as GitHub will setup HTTP redirects to the new URI.

[jurica]

I'm really sad to hear that, but I really appreciate your move to make that decision public immediately instead of letting the project rot and everyone uncertain about its status.
Even more I appreciate the work and effort you have put into zk. It has become my only note taking solution and it's working absolutely flawless for me. So I also want to use this occasion to say a big thank you to you for all that 🙏 !

I'm a software engineer as well and regarding the future of the project I'm also interested in supporting it and would like to offer my help if necessary and desired.

[mcDevnagh]

@mickael-menu
Should any of the following repos be transferred over as well?

• https://github.com/mickael-menu/tesh
• https://github.com/mickael-menu/glsp
  • it looks like your fork is just behind glsp and can be replaced with the upstream version
  • it seems like this is already the case

    zk/go.mod

    Line 5 in be1249d

    replace github.com/tliron/glsp => github.com/mickael-menu/glsp v0.1.1

• https://github.com/mickael-menu/pretty
  • this is just affecting test output, so I'm fine with using upstream if you'd prefer

I think zk-org should maintain its own dependencies. We can fork if you'd prefer.

[mickael-menu]

I transfered glsp and pretty to zk-org. I'll keep tesh for now as it's a separate project.

And yes, you can likely use the latest glsp version. Feel free to remove pretty if that's not helpful to you.

[mcDevnagh]

Maintenance Mode

I think for the near future, we should think of zk as being in maintenance mode: no new features, no refactoring, no new visions. Until we otherwise discuss, all future releases will be minor--0.14.x--and 0.15.0 will be the first post-@mickael-menu release, and we'll decide what that will look like once we get there. I'll take a look at some issues and see if we can clean up some pre-existing bugs. This should be a good introduction to the code base. If anyone would like to follow in that, please assign an issue to yourself once you start coding. Cheers fellas. This should be fun.

[mickael-menu]

That's fine, having one reviewer among the org sounds like a good plan (and better than no reviewer when I worked on the project 😄).

Maintenance mode sounds like a good idea until you get your bearings on the project.

[jurica]

Sounds good to me as well!
I took a look at the open bugs and quite randomly picked one (#273) to work on in order to get familiar with the codebase.

[julio-lopez]

As part of going into maintenance mode it may be a good idea to:

• upgrade old Go dependencies; and
• upgrade Github action workflows as well

Thoughts?

[Rahlir]

Speaking of bugfixes, I have been peeved by #194 because I have a lot of snippets for bash/zsh. I have looked around the codebase and I think there is a simple fix for this in lsp/document.go. I would be happy to have a go at this.

[jurica]

Green lights from my side, feel free to submit a PR for the issue.

[julio-lopez]

@mickael-menu Thanks for the hard work and making this available to the world.
I completely sympathize with the amount of time and energy it takes to maintain an open source project as the community grows.

@mcDevnagh Thanks for stepping forward to maintain the project.

I have barely started diving into the code, so not a whole lot that I can contribute at the moment.
I'd happy to contribute with minor chores around CI, and so on, in my almost non-existing spare time.

Cheers.

[tjex]

great!

[mickael-menu]

Thanks, Julio! I probably should have started a collaborative organization before getting burned out. 😅 Based on my experience, I didn't expect anyone wanting to help maintain the project, but I'm glad to be proven wrong!

[zalegrala]

Thanks for all the efforts. I've been using this tool almost every day for over a year and its become part of my flow. You can still send up PRs though @mickael-menu :). I'm happy to review PRs generally where I can if that's helpful.

[tjex]

Awesome to hear you're up for chipping in. Reviewing PRs is most definitely a great help! Thanks very much.

[Rahlir]

Hi everyone. Thank you for opening this discussion. I am very much relying on zk at the moment and I got a little freaked out when I saw the archive status last week. So I am very glad that this announcement and call was made.

I would also be happy to chip in occasionally with maintaining the project since I have been going through the source code lately and had some ideas for fixes and improvements. One thing I already have in the works right now (and was considering making a PR for soon) is proper zsh completion since this really helps my workflow. I would be happy to submit PRs for that in the near future. I think the call to stay in maintenance mode for now is a good idea. I wouldn't consider zsh completion new feature, but I will let the other maintainers decide once I am ready to submit the implementation.

Thanks @mickael-menu for all your hard work and vision. I really appreciate this project and I wish you all the best on whatever you are working next.

[mhanberg]

Thank you @mickael-menu, and good luck on your future endeavors!

[gwicho38]

Congrats on the next stage @mickael-menu! Looks like plenty of folks have filled the ranks :).

However, zk is good on so many levels. It is simple, portable, and modular. Fantastic tooling that I advocate for whenever possible.

Happy to help the project and maintainers moving forward.

[hugginsio]

Mickaël, thanks for your hard work on this project and making it available to the open-source community. You've built a terrific tool (and a great community around it).

To all the maintainers - should those of us looking to contribute stick with issues labeled as bugs while we are still in maintenance mode?

[mcDevnagh]

Yes, but I wouldn't call it a hard rule. We just want to avoid features for the time being.

The following would be accepted, but this is not an exhaustive list:

• bug fixes
• increase test surface
• improve documentation

If you have anything you would like to do at all, you can always open a discussion about it :)

[tjex]

On the documentation side, it could be a great time to look converting the documentation into a wiki. Navigating it isn't so great.

OR! even better, a Zk Zettelkasten vault as it's own repo. So we can have local copies and navigate with speed and ease 🤯

[hugginsio]

The wikis are great UX, but I can see the value in leaving the documentation under source control alongside the codebase as well.

I did notice the GitHub Pages site doesn't load an index.html, so the base URL throws a 404. I'll take a look at improving this behavior on my fork.

[tjex]

truuu. Totally overlooked that there actually was one!
That would be great 🙌

[tjex]

@zk-org/maintainers , i'm not sure if anyone's noticed, but I've made a master project here on zk-org. I figured it's better to have one board that can encompass issues and PRs across all repos so we have better oversight. It's ours, so feel free to add and modify as you see fit.

[mickael-menu]

That's a great idea 👍

[jurica]

I haven't seen that yet either. I also like that approach very much!

[jediaxe]

Thank you @mickael-menu for this wonderful piece of software, I have looked into almost every popular note taking solution out there and I choose to use zk everyday. It does exactly what I am looking for.

Anyone can see that alot of effort and creativity went into building zk to what it is today, I am not exaggerating when I say that zk is the best zettelkasten note taking app out there.

I agree with @tjex that @mickael-menu continued involvement in the zk project even if not full time is a good idea, it will bring peace of mind to everyone using zk knowing that the project wont stray too much off the initial vision that attracted everyone to zk in the first place.

Thank you @mcDevnagh for stepping up and taking over maintenance of zk! and thanks to everyone contributing to this project. I am more than happy to contribute in anyway I can.

[tjex]

thanks for chiming in :)
In terms of contribution, considered bug reports and also documentation contributions / fixes are great!
Also we should build up a little bit more test coverage, so if you're looking to learn the code base or get into Go, that would be a great place to start!

Other than that, we've almost tackled all the lingering bugs in the issue trackers, meaning we'll start considering feature requests soon too 😉

[mickael-menu]

Thank you for the nice words @jediaxe! I keep an eye on all the discussions and will chime in for the evolution of the project. Although it is a group effort now, so the future of zk should be lead by consensus.

I'll take this opportunity to thank @tjex for doing a stellar job in addressing the open issues.