Slowly I’m approaching the moment where I actually can spare time to contribute code to Discourse. This is something I have wanted to do for a while, but life decided otherwise. In the meantime, Microsoft acquired Github, which is for me, a free software zealot, an atrocious news because, even if Github was never a friend of software freedom, it was not its archenemy. Now, by the end of this year, Github should be fully owned by Microsoft, which may have changed since the 1990s, but remains itself, with questionable commercial activity and political moves that I simply cannot accept – this is a long story that I do not want to debate here.
In a world where Github became the normal way to discover and contribute to most software, how can I contribute to Discourse without a Github account? Do you accept emailed PRs and simple git contributions, and do you already have experience with such contributions? Would you maintain Discourse mirrors on other code hosting platforms? Would you update the development contribution guidelines to invite alternative ways to contribute to Discourse?
Usually what I discovered over the years is that people with an allergy to GitHub/Microsoft/JavaScript have an even stronger allergy to the idea of a CLA, so that kind of blocks all of this even earlier
Well, I did refrain from signing the CLA because of the situation that it can bring, that eventually Discourse could end up in the wrong camp. But my love for Discourse, along with such positions as @eviltrout’s (from his blog)…:
Yehuda Katz has done amazing work on Rails 3 and Bundler. When he tells me that he’s not going to abandon Ember.JS, I believe him, because he has a track record proving so. Angular, for example, is sponsored by Google, and while I think the project would continue even if they abandoned it, it is important to me that the Ember community didn’t spring out of a corporate sponsorship.
… eventually convinced me to sign it even with my expressed reserves. So that must make your argument obsolete.
I think the lowest friction option you have here is finding a community member less allergic to GitHub to submit the PRs for you. The way git works the can still be attributed to you.
I worry about committing the core team to handling patches via emails, this adds another complex bucket for us to deal with. I worry about a shadow gitlab cause again that would add more buckets.
Given the nature of Discourse, this might be a fantastic feature to be able to submit Git patches directly via Discourse’s email handler that would take care of this on anyone’s behalf, because then it would rely on Discourse’s infrastructure and not Microsoft’s. That said, coding this functionality would obviously require access to Github since one cannot code anything from outside. But dreaming is fine and if I get sufficiently proficient and motivated, who knows…
Another dream would be that defunkt gives away one billion dollars to Gitlab and they change their license to AGPLv3, but hey, we’re still using cars and qualify of being “green” energy sources that require mining down mountain tops.
It should be noted that developing theme components and plugins for Discourse would not require a github account, as you can download core anonymously and host your work on the platform of your choice.
I’ve been dealing with Git patch files attached to Redmine issues for many years, this tremendously slows down the overall development and review process. One short example: If the ref base commit is gone, or the patch doesn’t apply cleanly, you’ll end up with lots of manual work. Probably you could create a custom channel for that, but imho this feels wrong given the existing tool stack, proved working.
GitHub has a fine review process, even with inline code discussion and much more. In round about 1,5 years I can now really focus on reliable patch feedback, and merge a PR once approved.
In terms of GitLab, such a thing with reviews also exists. Unfortunately the approval workflow for merge requests is part of the enterprise version, not CE.
So, why bother so much about.a GitHub account? You’d only push your local source to a remote origin, create a PR (e.g. via hub CLI command), and hopefully get a merge notify if you want Bonus: Travis CI tests run on each PR and ensure quality without manual interaction.
Yeah, GitLab pulls a lot of this “enterprise only feature” stuff. Understandable, since they want to remain in business… but not exactly an incentive to switch from GitHub.
