I don't think it fair to the new contributor to have their contributions get caught up in the project politicking.
Gustavo Anatoly To be clear, ill-defined JIRAs consume the attention of those who are trying to follow along. Lack of clarity in the definition requires we need to keep an active eye out. When the issue is trivial, this is particularly irksome.
This issue is a good example. It starts out without provenance – does the issue come of 'code-reading', testing?, a user reported issue?, an attempt at setting bucket sizes in configs – and it has 'shoulds' and 'supposed to' in subject and original description but there is no justification as to why. Nick, a third party altogether, has to do detective work to elicit there is an actual problem here.
For another example, see the follow-on, filed again by Ted assigned to you, HBASE-11743. Look at it. It says this issue,
HBASE-11550, makes it "...such that there is no wastage in bucket allocation". But Nick resolves this issue with the comment that your patch ensures default and user-supplied config align punting on the wastage question... to he 'guesses' HBASE-11743. This is lack of alignment here. The mess that is this issue looks like it is to repeat over in HBASE-11743.
To avoid any crossfire in the future, I'd suggest file your own issues especially if you are trying to build yourself a bit of a track record. Also work on non-trivial issues as said before. You will find it easier getting reviewers if the issue is non-trivial.