In a recent discussion, some blame with respect to the current state of the CM project was thrown around carelessly by a user who apparently had a hard time understanding the nature of open source.

Having coordinated a number of projects and contributed on others, I understand the difficulties of ongoing development and support when burdened with the exigencies of needing to pay for life's activities. There are only 168 hours in a week, and when working 80 of them, there is literally no time left for anything else.

Rob noted that CM is indeed an OSS project, and that anyone is able to contribute. I have myself contributed in the past. However, my contribution has still not been accepted. CM is running on Mercurial, which is great for forking and sending pull requests, but those requests still need to be verified, which I understand is still work and leads to a similar situation of Rob not having the time, but unfortunately this leads to a situation where more is just expected of the coordinator if pull requests are not accepted or rejected with a reason - essentially it becomes just a "source available" project. This is a hard place to be in, and I'm familiar with being on both sides of it.

The biggest problem I see is the lack of unit tests. My contributions had been around submitting unit tests to the project to serve as the starting point for further tests.

The reason I'm writing this is that I think CM is the best UI framework out there, and I want to see it succeed, for both selfish reasons (I use it) and because it is a shining example of what a good framework can be - lightweight *and* powerful. I want to contribute. I want CM to evolve as the platform evolves. I want quality to remain high. I want a good community of contributors to emerge (like Castle and NHibernate has). The starting point has to be good unit tests to serve as the bedrock for all of this.

I'd be happy to continue working on the unit tests (as well as other improvements) I started if they will be a valuable part of the ongoing development of CM.

That is absolutly true.

I would also like to contribute, but if the pull requests will not be verified...the interest will be low.

What is with the other developers on the project?
They are allowed to apply the pull requests too.

@cb55555, cromwellryan and marcoamendola: How is your time on handling pull requests?

@Rob: This is a great project, don't let it starve out because of not applying pull requests.
If you don't have the time, maybe adding another developer is the solution ;-)

I think the other developers have sort of been in the same boat as me. In any case, I think I can start reviewing the pull requests in the next week. Normally i've been pretty good about that in the past, but it's just gotten away from me in the frenzy of things I've been doing lately.  We'll get it back under control soon.

Even if time wasn't an issue (though this is always a risk), the difficulty of objectively verifying and articulating the reasons behind pull request acceptance or rejection is much greater due to a lack of unit tests. It also increases friction between committers when there is no good external baseline on which to make go/no-go decisions. As a contributor, I'm much more likely to contribute to a project which provides tests since I can use them to ensure my contribution is solid and worthwhile.

That are great news.

Thanks for the fast response. I'm looking forward to next week.

Oof... I'm a dope. Just realized that my fork doesn't actually have a pull-request on it. Just added one.

I'm interesting in contributing, as I'd like to build some functionality around keyboard focus when binding views to viewmodels, based on some sort of attribute or convention-based approach. I've had a look but not yet found any coding guidelines (I'm talking things like where unit tests go and naming conventions rather than coding style, of course) - that might make accepting pull requests easier, as the only things that need reviewing are the actual functional changes themselves.

I know some projects (specifically I'm thinking of the Castle Project) will reject any contribution that is not backed-up by unit tests. Although with that said they're also quite strict on coding style etc as well so it's difficult to get changes accepted.

Thanks for this great framework - we at ByBox (www.bybox.com) are another real-in-the-wild user of Caliburn.Micro and I'd be honoured to be able to contribute a little something back.