[Bf-committers] Proposal for handling bug reports

Campbell Barton ideasman42 at gmail.com
Wed Jul 2 03:37:46 CEST 2014

@Jacob Merrill, What your suggesting sounds more like a
troubleshooting resource, Probably we should have this in our manual -
list common gotcha's, & solutions. The issue with first reporting
issues on a forum is users have to report twice and have logins to
both systems, so wouldnt want to make this the recommended procedure
for bug reports.

@Patrice Bertrand, good point :)

@Thomas, I'm a bit wary of automation, mainly because we should use
common sense when closing reports,
If someone has a bug on one platform, and 2 people on another fail to
redo it (the report may not appear to be platform spesific), closing
automatic wouldn't be any good.

Automatic moving back into the bug tracker when confirmed makes more sense.

In practice I don't think moving the reports really going to be a
bottleneck, if it is, we can check on automating it.

On Wed, Jul 2, 2014 at 7:37 AM, Thomas Dinges <blender at dingto.org> wrote:
> I support this. :)
> Can we automate the process a bit though? Like, if 2 other users can confirm the issue, the report becomes „Confirmed“ and part of the regular BF-Blender project again, or auto close it, if no one can confirm it in 2 weeks. Otherwise we also have to regularly check the Blender: Unconfirmed project to see if something is new here.
> Am 01.07.2014 um 20:36 schrieb Campbell Barton <ideasman42 at gmail.com>:
>> Recently we've been getting more bug reports, and its getting to a
>> point where I don't think we can usefully manage them.
>> Or, to do so, takes more and more time away from development.
>> A lot of the work ends up being communication and many times they
>> aren't even real bugs.
>> Just the time to reply to issues, ask user to follow our guidelines
>> and submit blend files,
>> asking what version of Blender they use etc...
>> Its demotivating to have 100's of reports and try tackle the bug tracker,
>> only to find many reports which are in some unknown status where
>> nobody can redo the problem or understands what it is.
>> Even being more strict and moving issues to TODO, only helps so much.
>> So I'd like to do this a bit different:
>> Proposal
>> ========
>> * add "Blender: Unconfirmed" project.
>> * If we get a valid bug report but can't redo it, we move immediately
>> to "Blender: Unconfirmed" with a canned response.
>> * 2 other people need to check the report.
>> * If after 2 weeks nobody can redo the issue, we close it.
>> This means users have some more responsibility to have others check
>> bugs, and redo.
>> It does risks closing valid issues sometimes, but at this point we
>> just have a bugs nobody can redo and nobody replies
>> to, so they arent useful to have open.
>> If the bug really happens for others probably it gets reported again anyway.
>> Of course if a report is incomplete we still mark as incomplete, if
>> its a TODO, move it,
>> this is for valid reports which give steps we can follow, but no way
>> to redo the bug.
>> Examples
>> ======
>> - https://developer.blender.org/T40881
>> - https://developer.blender.org/T40877
>> - https://developer.blender.org/T40870
>> - https://developer.blender.org/T40864
>> - https://developer.blender.org/T40858
>> - https://developer.blender.org/T40838
>> - https://developer.blender.org/T40788
>> - https://developer.blender.org/T40787
>> - https://developer.blender.org/T40784
>> - https://developer.blender.org/T40753
>> - https://developer.blender.org/T39591
>> - https://developer.blender.org/T34962
>> - https://developer.blender.org/T39467
>> --
>> - Campbell
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

- Campbell

More information about the Bf-committers mailing list