The future of this project

[Thomas De Schampheleire]

Hi all,

2017-06-15 3:32 GMT+02:00 Mads Kiilerich <mads at kiilerich.com>:
> On 06/12/2017 05:41 PM, Dominik Ruf wrote:
>>
>> Hello everyone,
>>
>> this mail is overdue, but I always hoped it would get better. :-/
>> I know this is a community project and we all have other responsibilities.
>> So I understand that a request does not get answered instantly.
>
>
> I understand and see your frustration.
>
> Not that it really answer your questions, but for what it's worth, some
> comments to your examples:
>
>> But for example my pull requests about 'repository settings' is now
>> literally waiting for YEARS.
>
>
> Yes. Also, the latest changesets in the PR still say WIP, suggesting that it
> not really is considered ready yet. The previous iteration got review
> feedback 2 weeks ago. I haven't had time to follow up on the latest one,
> having spent time on ...
>
>> Or lately my 'Port Kallithea theme to Bootstrap' pull request. I asked
>> multiple times for some feedback, but since 2 MONTH I got nothing. I
>> understand that reviewing takes time, but at least some kind of comment is
>> not too much to ask.
>
>
> Bootstrap has been very hard to land. Mainly because my initial requests for
> splitting things up with clean history so they were reviewable were refused
> or ignored. I have thus spent a lot of time trying to extract/redo and land
> parts that I could review and so I knew what was changed and why. The latest
> iteration of the Bootstrap PR is much better and we are making progress -
> thanks!
>
>> And some pull request like 'catch MemoryErrors when calling git diff' are
>> really trivial.
>
>
> Unfortunately, I also have the feeling that the approach in that PR is
> wrong. If we push the system so much that we get MemoryErrors, the system
> might start swapping and other things might fail too. Instead, we should
> make sure we don't use crazy amounts of memory but fail gracefully. But I
> haven't had time to investigate and propose a better solution.
>
>> This can not continue in this way. This project is now almost 3 years old
>> and we have very little to show for ourselves. In fact there were questions
>> if this project is actually alive (can't find the link right now). And I
>> can't blame anybody to think so. Kallithea has improved very little. Version
>> 0.3 is 20 month ago.
>>
>> So my questions to you guys is this:
>> What are your future plans for this project?
>
>
> My plan is to keep improving it, as contributions, time and priorities allow
> it.
>
>> Are there any chances that this project will start moving more quickly?
>
>
> Yes, if more people help by adding more resources and by helping us utilize
> resources better.
>
> Contributors can help reviewing, testing and improving contributions from
> others to the point where they are willing to put it in production right
> away and support it long term.
>
> Code contributors can also help by following the contributor guidelines and
> structure the code changes in such a way that they are easy to review and
> maintain.

Mads,
Thanks for sharing your view.
I think one 'quick win' would be if you could communicate more
explicitly on some matters. For example, if someone sent changes and
you are looking at them, possible reworking things, or testing it out,
then it would be helpful if you'd just reply with that fact. Then the
submitter is aware of it, and is not left in the blue.
Also, if you do not agree with a certain change or an entire PR, and
think it needs to be reworked in such or such way, or you're expecting
this or that before it can be merged, explicit (always polite of
course :-) ) communication could perhaps reduce some frustration about
seemingly 'ignored' changes.

Dominik,
Again thanks for bringing up this topic. I think we need to talk about
this and try to improve.
I hope it's not too late and we can still convince you to continue
contributing in this community.
As I said, I really value your contribution in the different areas you
attacked, be it testing, styling, bug fixes, functionality ... Due to
lack of time, I have not reviewed most of your changes, although I
realize that such peer review could help the changes moving forward.



A recurring factor in the discussion is the benefit of growing the
community: more developers means more mutual review and more bandwidth
to add new features or fix bugs. While there is no magic to do that,
there are definitely things that we could do.
For example:
- expanding the user base will eventually lead to more developers, as
users really are just potential developers. To do that:
  a. we should focus on adding important features (like SSH support)
above other improvements
  b. we should consider promoting Kallithea in a more active manner on
selected channels
  c. we should make frequent releases and use 1.0+ release numbers to
indicate the project is mature and active

- marking/tagging certain issues/features as 'easy' or 'for newcomers'
helps onboard new developers
- ...
There are certainly talks on this issue, for example:
https://2016.foss4g-na.org/sites/default/files/slides/Growing-an-Open-Source-Community-Lessons-Learned-from-Cesium.pdf


Of course, some of this is easier said than done, but if we want to
succeed we at least need to try.

I'm looking forward to your feedback.

Thanks,
Thomas