The future of this project

[Andrew Shadura]

On 13/06/17 20:23, Thomas De Schampheleire wrote:
> Below some of my input, with an attempt to structure it in topics:
> 
> Releases:
> - I agree that we should have more releases. In particular, once a bug
>   has been fixed, I think we should not wait longer than a max. amount of time
>   to create a new release based on the stable branch. For example, max. one
>   month.

I think we can do development releases too, just snapshots every $period
once things stabilised a bit.

> - For feature releases based on the default branch, we had quite some big flux
>   passing by the last year: pytest, Turbogears2/gearbox, Bootstrap. As these
>   changes gradually were taken in, I think it can be difficult to coordinate a
>   moment in time where things are stable enough to base a release on, while not
>   holding off some other changes for too long.
> 
> - While this seems like a none-issue, I have first hand evidence that at least
>   in some companies it does not: since we consider Kallithea as safe for
>   production use, we should use version numbers starting with a non-zero major
>   number, rather than 0.x. Some companies are effectively _not_ using Kallithea
>   just because the 0.x 'indicates' that it is not ready.
>   My proposal is to either jump from 0.3 to 1.4, or alternatively to 1.0, but in
>   any case not stick at 0.x.

I agree.

> Speed of intake of changes:
> - For my own changes last year, mostly pytest and Turbogears2 but also some
>   minor fixes, I can really not complain about response time for each iteration.
> 
> - The conservative approach of change intake, where a PR may need several
>   iterations with rework requests before being final, means that the total time
>   to get merged completely can be long, but it does make sure that the quality
>   of the new code is high, and the codebase as a whole only improves.
>   It requires motivation from the submitter though, and this may scare off some
>   potential contributors. Perhaps it could thus be helpful to relax a bit in
>   this respect, but swinging to the other extreme of allowing pretty rough
>   changes to be merged is also not a good idea.

It is difficult to hold balance between taking changes conservatively
and bikeshedding, I know thing myself from other projects as well. I
feel we're too conservative now, and while this makes sense, as you're
saying it may scare people off. And it does, even myself sometimes :)

> - I understand the frustration of Dominik regarding some of his PRs. I value
>   that he suggests improvements in different areas, even outside of
>   code such as Jenkins.
> 
>   On the other hand, taking the Bootstrap changes as example, it's not that
>   there is a total stand-still; things do seem to move and I see
>   several style-related changes coming in.
> 
>   We talked about this at the meetup early 2016 in Antwerp, and one of the
>   problems is the limited amount of review. There is only a very small amount of
>   people that review other's changes, most of the time just Mads himself. His
>   job would be much easier if others review the incoming changes and provide
>   comments to improve them. Unfortunately, the limited number of main
>   contributors is still small, too small it seems for good distributed review.
>   For myself, I don't have enough time to really play this role.

> Maintainership:
> - There are at least two aspects in maintaining a project: coordinating new
>   changes, and coordinating/handling user queries/issues. In practice, Mads
>   handles both tasks almost exclusively and he should get credit for that.
> 
>   I therefore don't think we should 'switch' maintainers. If anything, depending
>   on discussion on the other items, additional people could get commit rights
>   and help move the project forward.

I haven't realised my proposal can be understood this way, sorry if it
sounded too harsh. I didn't mean taking the maintainer's or
coordinator's role away from Mads. I merely suggested that because he's
apparently overloaded and we all lack sufficient time to spend on the
project, some of the maintainer's duties may — and probably should — be
offloaded to people who can and are willing to take them.

-- 
Cheers,
  Andrew