Hello Jacob, > Recently, I’ve noticed and opened a few reports that have a ‘[BUG]’ or > ‘[RFC]’ label in the subject, but also attach or inline a patch, which > causes BARK to classify them as patches [1].
Yes, I've seen that too and I recommend not mixing subject labels. I see these scenarios: 1. Someone reports a bug for which they do not have a patch 2. Someone shares a request for which they don't have a patch 3. Someone shares a patch to fix/solve an existing bug/request. 4. Someone shares a patch *directly* The question is: what to do in the last scenario? All direct patches are already implicitly fixing a bug or addressing a request: explicitly adding e.g. a "BUG" label somewhere in the subject seems to help maintainers to understand what the patch is about, but now the report contains two things to discuss: a bug (is it confirmed? etc.) and its fix. "Canceled" becomes ambiguous: is it about the bug or the fix? So I suggest this: either send a patch directly (and the discussion about the patch include the discussion about the underlying issue) or send two emails, one with the bug/request and one with the patch. Does this sound reasonable to you? > In the case of a bug + fix I could just split off the patch as a > response, but for an RFC + patch I can’t see a way to suppress the > machinery. PS: I'm not sure I see the difference between bug + fix and RFC + patch. -- Bastien
