Consider Slowing Down the Release Schedule!

[Boudewijn Rempt]

Hi Emmet,

Thanks for the input. I wish that all these timezones didn't exist! In any case, I'll put this on the agenda for today's meeting. You make a number good points :-)

Cheers,

Boud

On maandag 20 januari 2020 07:25:51 CET Emmet O'Neill wrote:
> Hey all,
> 
> I've been busy finishing up a personal project with Eoin recently, but this
> is something that I've been thinking about for a while and I'd like to
> throw it out there.
> I'm writing to the mailing list because I'm almost never awake for the
> weekly meetings (4-5AM on a monday isn't great for me. heh) and this is a
> better format than a series of IRC messages.
> 
> Anyway, two of Krita's goals for 2019 were to (a) drastically reduce the
> number of bugs and (b) to release every month.
> While you all did tons of great work on 'a' and we very nearly fulfilled
> 'b', I want to advocate for a different strategy in 2020:
> slowing the release cycle down to 1, 2, or (at most) 4 releases per year.
> Here's why...
> 
> *1.)* Less time between releases means less testing, and less testing
> likely leads to more bugs.
> 
> *2.)* Most people don't care for bleeding edge updates, they want a stable
> tool that works consistently.
> 
> I don't think the average Krita user is looking for a new version each
> month,
> and I'd imagine that most users are not following the release schedule
> closely or running the latest version.
> There are very few large projects, FOSS or otherwise, that release monthly,
> and for good reason.
> 
> In general, I think what users want is a tool that empowers them to create
> their artwork, while being solid, reliable, and consistent.
> On the other hand, those that do want to be on the bleeding edge have a
> number of ways to do that, including nightlies and building from source.
> 
> *3.)* A monthly cycle increases work without increasing reward.
> 
> There is an 'overhead' of time and effort associated with each release,
> from the community beta tests,
> to build and packaging process itself, to the patch notes, to the various
> platform submissions, to the various website and social posts, etc.
> At best (assuming everything goes right and nothing has to be redone) the
> work associated with this task is linear--more releases does not result in
> less work per release.
> 
> On top of that, a monthly cycle adds complexity to support, as 10 users who
> all downloaded Krita in 2019 might each have a different version.
> Even under the (big) assumption that a user has a version from within the
> last year, it's still difficult to know which version (and which bugs) they
> might have.
> 
> This amounts to a time/effort/support burden of our own design, when those
> resources could be used on something else,
> and there's really no evidence that it benefits either the project or its
> users in the long term.
> 
> *4.)* The community won't stay excited about small, incremental updates
> forever.
> 
> In my opinion, just like time and money, community interest is a *resource*--it
> can earned, it can be saved, and it can be spent.
> Getting the community to do things that benefit the project, be it
> donations, contributions, testing, or peer support are necessary *sinks* on
> that resource.
> This resource in particular is critical to the project's growth and
> survival, and it's the community, above all else, that we ought to nurture.
> It's absolutely worth considering, then, how we make sure that we're
> working with the community is a sustainable way.
> 
> Do we want community members to help with the burdens of support and
> testing? Yes, of course.
> Is offloading the majority of support to the community realistic? Maybe, in
> the long term.
> But, is getting a small pool of enthusiastic volunteer users to adequately
> test and fill out surveys every month sustainable? In my view, no.
> 
> After a few months, the novelty and the "sure I'll help out" attitude will
> run dry, especially if users are asked to test versions where changes are
> mostly incremental and opaque.
> New versions will go under-tested, bugs will be missed, the user experience
> will suffer and more time will be spent chasing bugs.
> Give the community work, and they'll eventually lose interest. On the other
> hand, give the community reasons to be excited and they'll be happy to put
> in some work.
> 
> Fewer, bigger, and more meaningful updates will give members of the
> community more reason to be excited, and I think it'll result in more
> people willing to do support and testing.
> 
> ---
> 
> At any rate, I don't want to diminish or undercut any of the work or
> successes that Krita had in 2019, as it was a great year for Krita by most
> metrics.
> But I also believe that a strong vision for 2020 and the future is
> necessary to make sure that the project continues to grow and that the best
> is yet to come.
> Slowing down the release cycle would help ease some of the current burdens
> on the project, and in my opinion,
> would also give us time to focus on making meaningful improvements and
> delivering cool new features instead of being caught in a constantly
> fluctuating tide of bug reports each month.
> 
> Give it some thought and let me know what you all think. =]
> - Emmet
> 


-- 
https://www.krita.org