I understand the takeover concern, it is a valid point. If I become the maintainer of application X, which was accepting pull requests, and I don't want to have a github account, I either have to create an account, find somebody on the team who wants to monitor pull requests, or change the project's policy. I still think that in this case the benefits on the advertisement outweight the problems (a change of policy due change of maintainership and nobody in the team wanting a github account).
On Saturday, September 19, 2015 05:36:09 PM Martin Graesslin wrote: > Pullrequests in the github are more than a way to submit a patch. It's also > code review. At the point where this would happen, part of the community is > excluded from participating in the code review process. Even more part of > our code actually moves to github. Previous versions of the patch are then > only available through github infrastructure. Any patch which needs any kind of serious reviewing will still have to go through reviewboard, nobody would use github's interface for that. How many these patches are clearly depends on the type of the project. For me a pull request is just a great opportunity to say: "hey, thanks a lot for your patch, I just pushed it to the main repository and it works great! If you want to continue submitting patches, I would suggest you get a KDE account by registering here <link>, so you have proper access to all KDE tools that help us in our development" while rejecting them autmatically isjust a great way to drive potential contributors away... Bye, -Riccardo _______________________________________________ kde-community mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-community
