Page 1 of 1

Rules for papercuts

Posted: Mon Dec 20, 2010 1:03 am
by CABAListic
What is a papercut?

A papercut is a minor issue with the Ogre API, like a missing function that you were expecting, an inconsistently named function, misleading or incorrect documentation, etc. Basically anything that slightly annoyed you at the time you had to figure it out, but not such a major issue that it kept you from doing what you wanted to do. A papercut should be trivial to fix.

Reporting papercuts

Please report any papercut you encountered in our bugtracker. Create a new report and prefix the title with "[Papercut]". If you feel there is need for a discussion about a proposed change, then open a thread in this forum and link to the corresponding report in the tracker.

Resolving papercuts

We want to get rid of as many papercuts as possible for the next major Ogre release (Byatis 1.8). As such, we will try to regularly squash any reported papercuts in batches. Your report is immensely helpful, as it makes us aware of the issue and also documents it in a place where it's easy to find and doesn't get lost.

Re: Rules for papercuts

Posted: Sun Jan 02, 2011 10:43 pm
by spacegaier
I just announced the initiative on the front-page to gain even more momentum and make our tracker burst eventually :).

So, keep the papercuts coming!

Re: Rules for papercuts

Posted: Thu Jan 20, 2011 12:40 am
by jacmoe
A papercut should be trivial to fix, otherwise it is not a papercut.
So, what is "easy to fix"?
A bug is easy to fix if it can be fixed by one person in one day. In practice, one or more people might work together over the course of a week to fix a paper cut, but if one competent developer cannot fix the bug in a single day, the bug cannot be considered a valid paper cut.

Many bugs become trivially fixable right before they are fixed. If a bug appears too complex to be considered a paper cut at first, it may turn out to be trivially fixable if it has a working patch that could be cleaned up and merged by one person in one day.