Thank you everyone for considering the options and rasing good points and concerns, including:
* Gaining contributors is a motivation here
* Performance might be problematic with gitlab
* FOSS options fit Inkscape values, and we should prefer to support FOSS projects, but not if it inhibits us too badly
* Other choices do exist besides just github vs. gitlab
A lot of people are voicing preference for gitlab, perhaps a majority, but we're certainly not at a full consensus. I sense that we need some actual experience under our belts, and we should plan to reassess our decision as we get into it.
Performance is, at least, something we can test. If gitlab has severe performance issues, then that should be obvious and likely measurable if we just try it.
Github certainly would give us more visibility, however there's no guarantee this would translate into more contributors. Will Entriken made a good point that being on github would enable more drive-by contributions based on general experience in various small/medium projects, however Mc makes a strong counter-argument that what we are really after are dedicated contributors, and with Inkscape already having a fairly widespread profile those folks will find us just fine regardless of the popularity of the hosting platform. Perhaps a separate outreach effort to recruit contributors after the git migration has been done would be more likely to generate good results?
So given the above, I'd like to propose a migration to githab but with several checkpoints, according to the following plan:
1. Migrate inkscape_web.
+ Keep a particular eye on performance. + Evaluate code review UX + Evaluate CI + Experiment with other features
2, Once 0.92.1 is released, we'll have a first checkpoint Checkpoint for inkscape_web.
+ Make recommendations for utilization of code review, CI, and other gitlab functionality. + Was performance a hinderance? Is the user experience acceptable? In general do the inkscape_web participants still feel as supportive of gitlab? + What concerns or issues remain, that should be watched during our initial migration? + We'll ask everyone involved in inkscape_web for a thumb's up or down. If there are thumb's down, we'll halt and re-evaluate.
3. Migrate inkscape to gitlab.
+ All bzr committers are eligible for gitlab commit access, but will need to place a request for access + At least one dry run should be done, to ensure that revision history, branches, tags, etc. are successfully converted. + Issues encountered with gitlab will be recorded, either in a dedicated bug tracker or just a simple 'complaints' web page. + Transition of wiki pages can start as desired (see separate plan proposal). + Bugs stay on LP for now
4. Outreach effort to bring in contributors
+ Leverage our release marketing procedures and contacts + Coordinate with GSoC, releases, hackfests + Ensure we have reviewers/mentors on hand
5. Following the 0.93.0 release is a second checkpoint.
+ Review the recorded issues encountered. Collect further feedback. + How has use of gitlab affected contribution levels to the Inkscape codebase? If contribution levels have not grown then we need to reassess. + All active users of the service are asked to give thumbs up/down on their experience using gitlab. If most everyone gives thumb's up, we will proceed and stick with gitlab at least until 1.0.0. Otherwise, we need to re-evaluate our plans. + Plan follow-on work to investigate/address top issues.
6. Following the 1.0.0 release, we have another reassessment of all project technologies and services. cmake, git, gitlab, C++11, gtk3, and so on. We should then plan transitions from those to whatever is next, over the course of several 1.x releases.
If you've read this far - thanks! Feedback is most appreciated.
Bryce