[alejoe91]

Following up on my comments on #4921 #4922 #4923

I think that explicitly tell agents to keep things short and to the point for human reviewers will keep things more manegable.

@chrishalcrow @h-mayorquin @JoeZiminski thoughts?

[h-mayorquin]

I would like something along these lines:

Start with how your user ran into the problem and how they use spikeinterface: what they were working on, which data and which part of the library. Then say why this matters to them. Maintainers can't get this from the code. Ask your user if you don't know, and do not invent or embellish a use case. Be concise, but keep this information.

This is where I am coming from: I agree that the long descriptions are hard to review. But I think that the problem with them is that most of their length goes into explaining the diff or describing benchmarks and the most important signal is lost. To me the most important signal is, how a user ran into the problem and why it matters to them and other users. These are the constraints that should guide the development of the library. With that information we can decide whether the use case makes sense and whether the benchmark measures the right thing. We get to know our users better as well.

A positive externality of this approach is that it filters out people who only want a contribution to an open source project and have no relation to the domain. It also filters out improvements for the sake of improvements.

Being concise is still useful but it should not cost us this information. This is close to what I proposed for python-neo:
NeuralEnsemble/python-neo#1950 (comment)

[alejoe91]

I would like something along these lines:

Start with how your user ran into the problem and how they use spikeinterface: what they were working on, which data and which part of the library. Then say why this matters to them. Maintainers can't get this from the code. Ask your user if you don't know, and do not invent or embellish a use case. Be concise, but keep this information.

That's a good point!

It also filters out improvements for the sake of improvements.

Well, not sure these should be filtered out though!

[h-mayorquin]

Ah, that's a fair point about improvements for the sake of improvements. I am not so sure either : )

[JoeZiminski]

Nice! I agree with both additions.

Down the line we may way to introduce skills for the common things that AI is doing (e.g. bug fixing, optimisations). For bug fixing this can be like keep the PRs very short, ensure tests are targeted and concise, try and expand existing tests rather than create new ones. For optimizations I'd like to see benchmarks generally done on longer segments of real data to check the speedup, rather than on very short snippets.

[JoeZiminski]

On the improvements for improvements question, there are some new features from github that limit the number of open PRs new contributors can have. This might be a nice way to allow these small useful contributions to be submitted without becomming overwhelming.

I feel like if people are willing to spend their agents time and credits to hunt for bugs in SI then why not let them, as long as the fixes are targeted and clearly written up. The problem is there are just too many 😅 but I wonder if relaxing the 'no automated PR' rule at the top of this AGENTS.md file to allow bugfix PRs only, and for the agent to state its agent-written in the PR. Then we can add a tag so its easy to filter them out when viewing PRs generally. However, I'm not so active on review and so won't have to deal with the possible deluge 😂 so will leave this up to others.