I'm only familiar with Windows and Linux, but I'll do some helps. However, please want more maintainers come.

I can maintain this, and have contributed to the package, yet my expertise is mostly Linux (with a little Windows and other *nix experience).

I'm not familiar enough with the fs event APIs of platforms, but would offer to help where I can.

Thanks @mattn @kolyshkin @adamdecaf. There is certainly plenty to do

I'm not sure who has what permissions, but I'm going to simplify our GitHub teams, and ensure you're all invited to help triage and close issues & review and merge pull requests. If there's anything you don't have permission to do that you need, please just ask

Open to help as well. I mostly work with Windows and Linux.

Thank you for adding me to the team.

A few questions:

• Is there an official way of (internal) communication between the maintainers (e.g. Discord or E-Mail)?
• Are there any planned features which you have in mind (other then feature requests via issues)?

Thanks for the questions.

• GitHub is the primary method of communication. There is an #fsnotify channel on Slack, but it isn't used very much. You can find it via the Slack link at the bottom of the official Go website. https://go.dev
• There are GitHub issues for planned features, though most were written a while ago (by me). The feature label is a good place to start. feature

I'm willing to pitch in too. Plenty of macOS and Linux experience.

Thanks.

I may not be able to provide much more guidance -- there are a lot of issues to look through and plenty to do on the code base once you have a good grip on the project. If anyone has any other specific questions, feel free to ask. I'll do my best to respond in a timely manner.

Also, for any macOS devs, the fsevents project has a separate issue base. It is needing some help getting the builds and tests working again -- particularly on M1.

I'm willing to contribute time and M1/Linux AMD64 builds - I've been using Linux for ~20yrs but MacOS is still somewhat new to me :)

Don't think I have the time to be a full maintainer but I will try to help out with some issues.

I have limited experience in the area, but I'd be certainly interested in learning more. Also, fsnotify is a dependency of Viper which I'm also a maintainer of, so I actually have stake in fsnotify staying alive.

How much does this job pay?

Hi Nathan, I am willing to throw my hat into the ring too.

I can help with testing.
I have a Linux server and Mac M1.
I can create a VM for freeBSD and help.

I have experience with Linux and little bit of FreeBSD but i don't have any experience with notification API or event API. I can help in any way possible. I can spend 6 hours on weekends. A few hours during weekdays depending on my workload.

@alwindoss Take a look at #419, which should cover the BSD testing once merged.

@gonutz This isn't a job. It's open source and maintained by volunteers.
Thanks all.

Hi @nathany , I am willing to help here

I'm able to contribute here. My open-source experience mostly relates to developing personal projects, but I've also made some contributions to yt-dlp (YOE would be ~2). My primary platforms are Linux and MacOS. I'd generally be able to contribute 3-5 hours per week.

Do we have enough maintainers to avoid archival?

Do we have enough maintainers to avoid archival?

Thanks to everyone willing to help contribute.

It's not so much a matter of number of maintainers, but rather having one or more of the existing contributors step up to manage the project, including making releases and adding new contributors.

#339 could use attention (Windows)

I'm happy to help, will start looking at issues.

Thanks @shogo82148 for preparing the 1.5.4 release and for everyone who contributed by responding to issues, reviewing pull requests, and contributing code changes.

While it's heartening that so many people are willing to help with the project, I still haven't heard from any person or group of people willing to take ownership the project (so that I can remove myself from it and know that it's in good hands).

That isn't huge surprise, as fsnotify has been in this state for over 5 years. Everyone is busy and fsnotify is not the easiest library to maintain.

I was planning to archive the project at the end of February, but never did. That is overdue. My hope is that archiving the project will result in someone maintaining a fork or creating a replacement library that is well maintained.

If anyone wishes to unarchive this project and take ownership of the namespace, they can contact me at git@nathany.com with references to Go open source projects they maintain.

Alright, I've been made an owner and unarchived the repo. I never saw previous calls for help (don't check the GitHub of a library you're using that often) which is why I never offered before.

I'll go through the open PRs and issues in the coming weeks.

Thanks @arp242!

I will try to help due I used this important library in production!

@arp242 Are there areas/platforms where you could use some help from others who have responded to this thread?

@arp242 Are there areas/platforms where you could use some help from others who have responded to this thread?

Help is always appreciated, of course; I've been doing this programming thing for a while across many platforms, but I don't know everything and there's lots of subtle things in fsnotify. And my time is not infinite either.

Everyone is just a volunteer, so I don't know how to best organize these things. At the end of the day what this open source things kind of comes down to is "contribute if you feel like it". Maybe we can add some teams like @fsnotify/windows, @fsnotify/linux, @fsnotify/freebsd, etc. people can join? Then people can explicitly join those and they can be used for pinging people. Right now the fsnotify team has 36 people and I'm hesitant to ping all of them. Maybe just @fsnotify/core or something would be enough.

I guess the biggest challenge is triaging the backlog of issues; I went through quite a few of them yesterday, and many are somewhat unclear and/or hard to reproduce. I suspect many are also duplicates in the sense that they're caused by the same underlying problem, but hard to be sure.