Re: CRS Issues being automatically closed?

Thanks Christian and I apologise for my original message being a bit
blunt.

-----Original Message-----
From: Christian Folini <[email protected]>
Sent: 11 January 2021 14:03
To: [email protected]
Subject: Re: [mod-security-users] CRS Issues being automatically closed?

Hello Jamie,

On Mon, Jan 11, 2021 at 12:10:03PM -0000, Jamie Burchell wrote:
> Thanks for the response and apologise for posting in the incorrect list.

No worries.

> Great to see there is things in development to address this.
>
> I just wanted to re-iterate that the issue I raise is not one of
> expectation for anyone to look at the issues reported (in their spare
> time or otherwise) - I fully understand your points here. Rather, I
> would just prefer to see current issues not automatically closed and
buried.

Ah. Thanks. We're full of guilt already, so my reaction tends to be a bit
on the defensive side when it comes to this topic.

The issues are not gone, they are just a bit hidden. But I have now added
a link to a query that lets you filter for them on github. The link is in
our README and also on the coreruleset.org website. I think we should have
added this before and also documented the process much earlier. Thanks for
pointing it out.

Cheers,

Christian


>
> Best Regards,
> Jamie
>
> -----Original Message-----
> From: Christian Folini <[email protected]>
> Sent: 11 January 2021 07:21
> To: [email protected]
> Subject: Re: [mod-security-users] CRS Issues being automatically closed?
>
> Hey Jamie,
>
> This is the mailing list for the ModSecurity engine. The CRS project
> has a separate mailinglist over at
>
> https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-proj
> ect
>
> But let me answer your question nevertheless:
>
> You are correct and this configuration to close stale issues after 120
> days is offensive. And we did not take it lightly. We have been
> struggling with not being able to address all the issues for years. We
> tried different methods, scheduling, assigning, highlighting, inviting
> the wider community to help, tagging as "#goodfirstissue" etc.  But it
> did not bring a real solution: The issues pile up and new issues (also
> vital ones!) can end up buried under a pile that is too big to plough
through.
>
> As most open source projects, CRS is a volunteer driven project.
> People work on CRS because they want to work on CRS. Some steal time
> from their companies to do so, some put their children to bed to hack
> away. But it is always time that our developers give to the project
> freely. I as a co-leader of the project can not force issues into
> their hands. All I can do is making CRS a fun project to work with and
> prepare the environment in a way that makes it easy and cool to work on
CRS.
>
> And the huge pile of issues started to have a chilling effect on
> developers or new developers. There is a moment where the pile is so
> big, you are not even addressing what you can address because of all the
rest.
> Looking at the
> 36 issues open right now feels managable and most issues are being
> addressed.
> (You can tell easily, since most open issues do have a conversation
> history.)
>
> So we talked about the step a big deal and we took the decision about
> a year ago.  Ultimately it was a decision to pick between the goodwill
> and health of the developers and the goodwill of individual users. I
> am really not happy with the way it is and I have a new plan to help
> us address all the issues before they get stale. But it is not quite
ready to share.
>
> What can you do: If you care about an issue, then comment on it. We
> read every comment on every issue. If get the notice that the issue
> has been tagged for removal (the tag "Stale issue" is being applied 2
> weeks or so before it gets closed), then comment on the issue and tell
> us you still care. Also multiple users chiming in give an issue priority
in our eyes.
> We currently do an issue chat once a month (3rd Monday every month),
> where we look into 5-10 open issues. One way to make sure an issue
> makes it into that meeting is the tag "Meeting agenda". Ask us to add
> this tag and we will take it on the list.
>
> All in all, using the services of the stale issue bot is not a sign
> that we do not care. Quite the opposite. We care a lot and we feel bad
> about using the stale issue bot. But it was the only solution we saw.
>
> Hope this explains our reasoning a bit.
>
> Best regards and thanks for speaking up,
>
> Christian Folini, CRS Co-Lead
>
>
>
>
>
>
> On Mon, Jan 11, 2021 at 12:49:17AM +0000, Jamie Burchell wrote:
> > Hi CRS Team
> >
> > I'm disappointed to see that issues I'm reporting (FPs) (e.g.
> > https://github.com/coreruleset/coreruleset/issues/1864) are being
> > automatically closed by stalebot. I fully understand that there may
> > not be the time nor the resources to address issues reported, and I
> > know why stalebot exists, but I don't think rule issues that people
> > have spent time looking at and reporting should be closed before
> > they are actually addressed. It certainly doesn't encourage me to
> > continue reporting them moving forward.
> >
> > Cheers, Jamie
>
>
> > _______________________________________________
> > mod-security-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > http://www.modsecurity.org/projects/commercial/rules/
> > http://www.modsecurity.org/projects/commercial/support/
>
>
>
> _______________________________________________
> mod-security-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>
> _______________________________________________
> mod-security-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/


_______________________________________________
mod-security-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/


_______________________________________________
mod-security-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/