I think it's probably right to mirror the method names used by scala.math, but I would suggest that you make the Scaladoc slightly more descriptive. In particular, Returns the rint value doesn't mean much unless you're pretty familiar with the methods from scala.math. I would spell out ceiling and copy the language from the rint documentation. (I think this falls under fair use.)

There's an argument that rint should be called round, which is the name used for the analogous method on Double. However, that returns a Long instead of a Double. I think I agree that rint makes more sense since scala.math.rint has more directly analogous behavior.

I personally find it a little unfortunate that the scalar part of a Quantity is always a Double. (If we had Quantity[Double, A], I would suggest we do a .round that gave back a Quantity[Long, A].) That said, a discussion about parametrizing the scalar part of a quantity is obviously out of scope, and I don't think adding these methods makes it any more difficult to do that in the future if there was an agreement that it was an improvement.

As a matter of bookkeeping, my projects have generally done an "approve" when there are only trivial changes requested, rather than a "request changes." If the committer agrees with the suggestions, they're made and merged without further review. If the committer does not agree, then we hash it out in chat. (I believe "request changes" will force a second approval, which seems overkill for the changes I've requested if we're assuming good faith.) Do we have a policy for this project?