(Resent because sending to both -hackers and -www gets emails put in the moderation queue, and I don't want to introduce that delay to all replies. If you received the previous version because you're in the CC please only reply to this one)
# Background As some of you might have noticed I've been trying to breathe some more life into development on the commitfest app[1], both by contributing myself but also by encouraging contributions of others. Basically I'd like to become one of the maintainers of the commitfest app project. The process to get there has been much more of a struggle than I'd hoped... So far I've been sending patches privately to Magnus (who is currently the only maintainer afaik). Sadly, Magnus usually has a lot on his plate so he often takes a while to respond. This has made the turn-around on getting my patches deployed pretty long (even for minor patches). I requested Magnus to give me commit access to the pgcommitfest repo so that I could deploy improvements without having to wait for his reviews. He didn't think that was a good idea. It turns out we fundamentally disagree on what's acceptable way to deploy: Magnus wants reviews before deployment to be required, in an effort to get as close-to-perfect commits as possible. I, on the other hand, think that the benefit of close-to-perfect commits is not worth the delays in deploying that those reviews currently introduce. I'd rather deploy code more often to get feedback from users, and make quick improvements/fixes based on that feedback. (this "deploy early, fix quickly" approach is also what's being done for cfbot repo and I haven't heard any complaints about it) After some private emails back-and-forth, one thing that we both do agree on is that it would be good to move both development and discussion of new features into the open. So I thought it would be good to also discuss in the open, what exactly that should look like. # Proposal for new process I think the following set of guidelines would be a good start: 1. Development happens on GitHub using Pull Requests (PRs) and Issues (see last section for why GitHub). Currently that's on my mirror of the repo[2], but that could be moved under the official "postgres" GitHub org. 2. Chat discussions around development happen on the #commitfest-dev channel on the PostgreSQL Hacker Mentoring Discord[3]. 3. Ideas for new features should be discussed on the pgsql-hackers mailinglist to make sure that the users of the commitfest app don't hate the idea. 4. Small incremental improvements to existing features and bugfixes don't need pgsql-hackers involvement. 5. Reverts and trivial fixes (typos/forgotten check for None/etc) can be deployed without review 6. "Big" changes should bake in the staging environment for at least a week. 7. If you're deploying a change, you're expected to be reasonably available in the next few days after to resolve issues (by reverting or hotfixing). 8. Feedback/complaints about newly deployed changes can be given on pgsql-hackers (CC-ing the committer & author) or through GitHub issues. Then there's some open questions that require some more discussion: a. Do all changes that don't fall under 4 require a review? Or are there certain changes that don't need one (e.g. HTML only changes)? b. Who can deploy? i.e. can I deploy PRs by other contributors after I approve them? An example being [2]? Or is Magnus the only person? c. Is there some time after which a PR can be deployed without review, even if normally it would require review? i.e. because no-one reviewed it in "a reasonable" amount of time # Call for reviews Magnus also suggested that I ask more people for a review of my existing commits. That seemed like a good idea, so I created a PR that contains all the currently not-yet-deployed patches[5]. Note that normally these commits would be separate PRs, not one big PR, but given this is a new process and they are already deployed to staging like this, I just did it this way. I can split them up too though, if people prefer that. (just let me know) You can try these changes out on the staging website[6]. For now that requires credentials, but I hope we can make it publicly accessible soon. Until that happens just ping me for the credentials. # Why GitHub? 1. GitHub has CI and issue/patch tracking included (hosting a commitfest app + cfbot instance, just for commitfest app development seems like a pain) 2. Web developers are generally much more comfortable with GitHub than sending patches over email, so this makes the lives of new contributors much easier. 3. cfbot development is also on GitHub [1]: https://commitfest.postgresql.org/ [2]: https://github.com/JelteF/commitfest [3]: https://discord.gg/XZy2DXj7Wz [4]: https://github.com/JelteF/commitfest/pull/4 [5]: https://github.com/JelteF/commitfest/pull/7 [6]: https://commitfest-test.postgresql.org/
