More specifically, frequency of commits gives you an idea of whether someone is actively working on something or not. No commits means they are not writing code.
In theory a developer should commit their work on a daily basis even if it is incomplete. In practice any developer that goes weeks between commits is likely doing something else other than coding.
The specific definition for a github (or other source code management systems) commit is: A "commit" is the action performed by a developer to contribute or commit code to the source repository. As toast says it is only a rough gauge of activity. A simple spelling error in a code comment could be fixed and committed and that increments the version / commit number, tho it had zero effect on the functionality of the code.
To somewhat counter to BM's first sentence, it is possible a developer is actually doing coding work but hasn't checked in (committed) changes yet. As BM went on to explain, following good coding practices would mean regular commits, generally a minimum of once per day. However, there are a number of reasons the frequency might legitimately less than once per day. It really depends on the urgency of the changes, whether the programmer might be doing work while on the road or whether the code is for a brand new feature and has no other dependencies and is a prototype / work in progress / experiment.
The point is there are exceptions to the a daily commit schedule. In general it should be done quite often. It reduces the risk of loosing changes and provides a very important control point, especially where many developers are working on the same project. When it comes to open source projects like BitShares it's important to keep everyone syncronized and on the same page so to speak.