Re: [boost] Boost summer of formal reviews

Subject: Re: [boost] Boost summer of formal reviews
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-03-11 19:57:20

On 12 Mar 2014 at 7:54, Vladimir Batov wrote:

> > What I'd really, really like is if the review schedule also listed
> > answers to at least the following questions so queue submitters have
> > a better idea of what is demanded:
> > ...
> Apologies for truncating your long list of "demands" :-) ... done so 
> only to keep the conversation short and flowing.
> 
> That is a seriously big list... and IMO unreasonable given the author 
> has no guarantees whatsoever that all that effort will not be wasted... 

Sorry, I probably wasn't clear: apart from the CI test requirement, 
all fields are *optional*.

> if the respective library is rejected for completely different reasons 
> -- high-level design, applicability, you name it. More practical (less 
> off-putting) IMO might be 2-level review when an idea/design, API, 
> first-cut implementation and readable/sensible documentation are 
> presented for evaluation. If that's rejected outright, then it saves the 
> author a lot of effort that he might direct onto improving his original 
> design/offering. If the initial concept is accepted, then the author 
> would have a real incentive to keep working and improving his original 
> submission behind more/less stable and already-approved API. I think in 
> reality that happens all the time in Boost (or any public library for 
> that matter). Spirit's considerable evolution/transformation might be an 
> example.

I'm also not unsympathetic to this - after all, witness last week how 
only Vicente responded to my request for a design review for a 
generic continuation monad framework.

Equally, I would say that writing top notch software is something you 
get to do rarely at work because management never lets you finish 
properly, or if they do let you finish, most of your workload is 
filling in never ending compliance forms and statements and 
repeatedly explaining your implementation to people who can't 
understand in presentations rather than coding. For me, at least, 
properly finishing software is why I exchange family and personal 
time for writing open source - it keeps me sane when working in 
corporations where it's very rarely a positive coding environment. In 
other words, writing top notch software I find rewarding in itself, 
because I never am normally allowed to.

Niall

-- 
Currently unemployed and looking for work in Ireland.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/