[PATCH] D53691: Introduce bug life cycle documentation.

[James Henderson via Phabricator via llvm-commits]

jhenderson added inline comments.


================
Comment at: docs/BugLifeCycle.rst:46-47
+Make sure that you have one or more people on cc on the bug report that you
+think will react to it. We aim to automatically add specific people on cc for
+most products/components, but may not always succeed in doing so.
+
----------------
Maybe this should contain instructions on how to identify a good person to add as a CC? I imagine a good basis is the same as the people you'd add as reviewers for a change in the area.


================
Comment at: docs/BugLifeCycle.rst:96
+Closing bugs is good! Make sure to properly record the reason for closing.
+
+Examples of reasons for closing are:
----------------
kristof.beyls wrote:
> RKSimon wrote:
> > Do we need to distinguish between resolving and closing a bug? We have verified/closed states but AFAICT these are barely used.
> Good point.
> As far as I can see, we don't really attach much difference in meaning to the "RESOLVED", "VERIFIED" and "CLOSED" states.
> Therefore, my opinion right now is that we're probably best of to just remove the "RESOLVED" and "VERIFIED" states from our bugzilla instance and only keep the "CLOSED" state, making the workflows simpler.
> I do think that this change can be made mostly orthogonally to completing this documentation. If/When we remove the "VERIFIED" and "RESOLVED" states, the documentation becomes less open for interpretation.
> What do others think about this?
This is purely a personal opinion, but I would prefer to keep RESOLVED, above VERIFIED or CLOSED, partly because that's how I'm used to using bugzilla (I've always used RESOLVED). However, if consensus is against me on this, I don't mind. If we went down this route, you should probably change "closing" to "resolving" here and elsewhere.


Repository:
  rL LLVM

https://reviews.llvm.org/D53691