On Thu, Apr 13, 2017, at 23:34, Vighnesh Birodkar wrote:

I understand where you are coming from. But don't you think there are instances when a contributor , after working on a new feature or function, does not have the time or energy to drive their work towards completion. The pending work might be too much for a single developer but it may be something that multiple developers working together might be able to complete.

These features need not have to be part of the next release. But my assumption is that if one these features is useful, it will quickly get polished and be good enough to be exposable. If a feature works and is kept isolated from the public API, its tests/docs/optimizations can come from different other developers at different points of time.

Importantly, each piece of contributed code needs to be maintained. I am not encouraged, when a contributer is unwilling to go through the necessary care to figure out API etc., that they will stick around to fix bugs and update documentation later. In fact, that increases my hesitance to merge, because now not only will they be gone, but we'll be stuck having to fix up their code later.

So, while I am all in favor of lowering barriers to entry—mostly arround annoying grunt work—certain other barriers remain useful. My preference is for a smaller but higher quality library, with a lower maintenance burden (especially since we rely on volunteer effort for now).