Official Fork?

[mrfroggg]

Qmando doesn't give any update and he has been saying, for many months, that he'll soon come back with an official strategy to transfer the project ton another maintainer.
Users are still asking questions / opening issues in the main Elastalert repo, probably most of them don't know about this "alternate" EA as it's hard to find if you are not looking for it.

On my side, some people around me are starting to question if we need to replace EA because of the lack of development on the official repo.

So, is it time to do an official fork? I think we should not wait anymore for Qmando/Yelp, from what I understood, they are not using Elasticsearch anymore.
@jertel and @nsano-rururu have been working hard on EA!

Fork name could be: elastalert2 with a 1.0 release!

[ferozsalam]

I am in favour of this as well, this project has regained some momentum with this fork and I think it would be a shame not to make the most of it.

My only note would be that having the name 'Elastalert 2' with a 1.0 release number could be slightly confusing. Perhaps something like 'Elastalert Neo' or similar to indicate it's a different project but not tying it to a particular number? In any case this is only a minor detail.

[mrfroggg]

yeah, I found out that @jertel created a pypi release of "elastalert2" with version 2.0.2 (February release), so it might be the way to go

[Shashankft9]

I observed that both @jertel and @nsano-rururu have different forks?
https://github.com/jertel/elastalert
https://github.com/nsano-rururu/elastalert

Perhaps we can get just one new source of truth first? And have the same people as maintainers?

[ferozsalam]

I think that all sounds reasonable!

Given the number (and the low quality) of most of the issues raised on the Yelp Elastalert repo, I think we should pre-emptively consider how issues should be handled, and ensure that we're only keeping issues around if they are valid and we are planning to fix them. I know that it's sometimes seen as a controversial, but something like a stale bot might be the best way of keeping noise down.

[mrfroggg]

I agree with @ferozsalam , valid issues should only be kept, call for help/support should be done elsewhere.
In my previous work contract, I worked a lot with Netbox (https://github.com/netbox-community/netbox) and the repo admin was pretty strict and it worked very well, issues are super clean! They also had the stale bot.
They have a Google Group for discussion / support.
On Yelp/elastalert, they have a chat-kind of thing for support, but I have to say that I never found anything useful in there, we should propose something a bit more useful.

@jertel : 'transform this repo to an official fork', yes, it's what I had in mind: issues, documentation, release! Feel free to start on it! I can create a Google Group or something else for support requests.

As for the '2', I agree for Elastalert2!
As an example, I use iTerm2 everyday on my Macs, it replaced the original iTerm. iTerm2 is now at version 3.4.5, the "2" is not bound to version 2.X

[ferozsalam]

We could probably continue using this Github discussions board for support requests, rather than creating a separate Google Group - it seems to have everything we would need.

[jertel]

I agree with the issues problem, and that's why I turned off the Issues feature for this repo when I created it. I felt that I'd rather have people ask for help in Discussions, and if it's a legitimate issue then they or someone else perhaps can issue a PR for it. But if we have multiple maintainers here willing to moderate an issues list, and potentially a stalebot to close out those that have lost interest, that's a good solution too.

I think the Discussions forum will be OK as a place for support requests. Even though it's a new GitHub feature I've been using it with good results on other projects. It's had a very quick adoption rate.

[Shashankft9]

+1 for github discussions, would be better to start off with less places so that they can be easily maintained, if later on people feel would like to branch out to google groups, that would also be fine I think.

[ferozsalam]

Just seen all the updates, thanks @jertel it's looking good!

[devinbfergy]

I am down for @jertel and that fork being the new elastalert2.0

[anthonylavado]

@jertel One thing to consider - searching through code with the GitHub search is unavailable for forks. Over at Jellyfin, we had to contact support to request that the fork relationship be "broken" so that repositories we've forked could have full capabilities. It may be worth doing that for your repository. Yes, it does take it away from the "network", but it lets this project live on independently.

[jertel]

Thanks for sharing this. I spent a fair amount of time searching GitHub for a way to break the chain and came up empty handed.

Also, thanks for your contributions on Jellyfin - great project!

[jertel]

This repo is no longer attached to the original elastalert repo. Thanks again for the recommendation.