Topic suggestion for next Kong Community Call

Dear Kong Team,

I’ve been listening offline to the first Kong Community Call.
Working on Kong for more than 2 years, I’m starting to get good fun in developing around Kong (already a couple of simple PRs pushed) and Kong plugins (a bit less than 10 quite complex plugins developed, and trying to convince my management to opensource one of them that provide an implementation for !).

However, I’m still a bit afraid to push more important contributions to Kong repository as I’m not really mastering Git/GitHub, or let’s say the constraints you might put on the contributions!

Of course, I’m not at all challenging your constraints and guidelines (!); I’m just a bit uncomfortable and I fear not to match them ! For example, I spent a full day for my last contribution to squize all the commits I have into a single one… because I somehow corrupted my main trunk with my former PR as this PR has not been accepted as is but integrated manually by yourself (so the intermediary commits I had on the main trunk of my fork were bothering me !). Following this experience, I have in mind that it is better for me to work on branches of my Kong fork rather than on the main trunk… But I’m not sure about that and I would love to get some recommendation from experienced people!

This being said, and in order to give confidence to potential contributors like me :stuck_out_tongue: , it would be very helpful if you could spend a bit of time during one of the next monthly community calls to provide such best practices for Contributors to Kong OSS.

Not really to talk about coding style (what’s written here is very clear), but maybe an opportunity for you to recall the main tricky dev concerns, what is the best way to manage our forks, naming and other rules related to the PRs (even if clearly stated in the page mentioned above; but what about “WIP”, “do not merge”, etc.), how to manage tests (separated commit… but how ?), how to integrate new updates into an existing commit (following your review, for example), Travis auto-test triggering (in our fork), how to make a proper rebase of our fork and on the branch of our fork, etc.

Even it is maybe a bit like “GitHub for (dummies?) Kong-ers”, hoping it makes sense to you as well !


I am all for a GitHub for dummies driven by a few Kong engineers. They could point out the most common PRs and walk through it from start to finish to show different common examples of how to fix up an existing PR like they prefer it(when its currently in a bad state). Then with a recorded community meeting they can link that back into their contributing info and hopefully help out Kong Github newbs :slight_smile: .

1 Like

Hey guys, We had a discussion about it, and I think there’s a little more work we have to do to streamline the contribution process for new contributors to Kong/kong. But in the meantime, in honor of Hacktoberfest, @Cooper will be discussing how to contribute to the docs. Check out the agenda for how to join.

@pamiel I’d love to talk offline about what trouble specifically you ran into! Want to email me at and maybe we can schedule a call?