Ihor Radchenko <[email protected]> writes: >> See https://tracker.orgmode.org/next/bark-manual.html > > +1
Thanks for your feedback. >> Yes, I've seen that too and I recommend not mixing subject labels. > > Note that we have some instances when subject labels do get > mixed. Most likely because M-x org-submit-bug-report prepends [BUG] to > the subject entered by the user. Sometimes, that subject already > contains something like [FR]. Could we have M-x org-submit-feature-request and M-x org-submit-patch? This way we would make users aware of these possibilities and the BARK conventions would be easier to discover and follow. M-x org-submit-feature-request would guide the user through what a good feature request is, encouraging users to check if a similar request has been made already. M-x org-submit-patch could check [PATCH] gets prepended to the subject or that the attached patch is well-formatted. Nothing to clever, just interactive guidelines to talk to the tracker. > Here is the latest example: > https://list.orgmode.org/cao48bk-xx8qry826q7j_aabqaz18ilcpn+dpbpqgdb31nsm...@mail.gmail.com/T/#t The clearer the information we receive upstream, the less processing is required downstream: I'd encourage submitters to decide if this is a bug report or a feature request. If they want to submit both, it's better to send them in separate emails, because probably two distinct commits will solve them anyway. > I have also seen [BUG/FR] (when the author is not sure). It's okay for BARK not to catch everything - in those cases, a human can disambiguate and promote the email as a bug and/or a feature request. -- Bastien
