Document structure and purpose of detectors in README

[omkar-foss]

Add a new section in README to document structure and purpose of all detectors in detection package in detail.

It'll help in near future when new detectors will be added.

[MoralCode]

My initial interpretation when the feature was introduced was that each detector would be focused on a different source of data. (Commit message, commit author, commiter, commit contents, general text, git refs, etc) and that each detector would be able to return multiple results for potentially multiple different AI models/tools if that source indicates that more than one were used.

I think for me a data source would be basically defined as a different method of data collection. For example the way git refs are fetched are obviously going to need to be fundamentally different from how you look at commit messages. That said, there's also a lot of potential for reuse. For example, if you're already parsing the commit message to look for trailers, then I feel like it makes sense to add support for a new trailer in that process, rather than making a whole new detector that duplicates the commit message parsing process (even if its just a function call)

This combined list of detection results across all the detectors would then be processed as one list and scored and sorted and filtered and whatever else before using it to make decisions based on users configured threshold settings.

[omkar-foss]

In detectors except for gitnotes and committer, all others (coauthor, message and toolmention) read commit message separately right now. We could de-duplicate the commit message parsing by passing the commit message as an argument to these detectors.

[omkar-foss]

I feel like it makes sense to add support for a new trailer in that process, rather than making a whole new detector

We could merge coauthor, message (and assistedby from #33) into a single detector to keep all trailer-related detectors in one. But current structure of message detector is quite different and it doesn't seem to support multiple instances of same trailer, so it could be quite a bit of restructuring.

[omkar-foss]

This combined list of detection results across all the detectors would then be processed as one list and scored and sorted and filtered and whatever else before using it to make decisions based on users configured threshold settings.

I feel we'll get a clearer picture of this when we start with scoring (#12), so I guess it'll be great if we could continue with having a separate trailer for Assisted-By like there is for Co-authored-by, document the detectors as per this issue, and then we can plan take up any restructuring as a separate item.

[MoralCode]

I think my initial thoughts on what detectors were was something along the lines of: "each new general way/system that AI can be disclosed gets its own detector unless it is functionally the same as an existing detector"

Examples:

• disclosing your AI use in a commit message (less structured) vs a trailer (more structured) is something that I think warrants two separate detectors because the techniques used to parse the information in both places may be different and we dont want one holding back or being too overkill for the other
• supporting different trailers (co-authored-by, assisted-by) i think should be in the same detector since the logic for parsing one trailer likely doesn't differ too much
• detecting AI use in commit author vs commit committer fields should be in the same detector because they both require basically identical parsing code.

although that makes me think of a potential conflict: co-authored-by data is physically located somewhere else (commit message trailer) but conventionally it should be well-formatted and needs BOTH the same structural parsing to locate it as the commit trailer detector, AND the same data parsing as the authorship detector.

What do you think of separating the ideas of detection and parsing? maybe something like this

[omkar-foss]

What do you think of separating the ideas of detection and parsing? maybe something like this

@MoralCode I like this idea, but I suppose this'll require significant redesign of current code structure, right? So could we may be pick this as a separate sprint?

My suggestion is that we could release Assisted-By detection as a feature to users, and then separately continue with internal code structure changes of separating parsing from detection, as I'm sure it'll take longer to release, and shouldn't block feature/functionality releases.