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 https://github.com/Kong/kong/issues/155 !).
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 , 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 https://github.com/Kong/kong/blob/master/CONTRIBUTING.md#code-style 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 !