So some random thoughts, and I'm still on the fence. We clearly have a problem with discoverability, partly due to our infrastructure issues, partly due to the new generation of 'open source' developers thinking the world revolves around Github (*). One of those things we have the power to fix, the other we don't. For the latter a Github mirror would seem to make sense, but it would need to be carefully managed (by who?). For the former the SysAdmins are working hard and I look forward to the results. If we can offer a Github-like experience (**) while keeping our independent infrastructure that is easy to use and discover and ranks top in google then brilliant. But we need to think about this in terms of the entire new developer experience, and we've been failing badly on that for a while.
(*) Actually they're nor Free or Open Source devs, they're just devs looking for code to use or to share their code, and don't care what the licence is or philosophy... (**) How much of the issue is just the poor state of FOSS hosting solutions? We're software devs, can't we fix that? How will having multiple mirrors affect google rankings? Will there be a page full of repos for a confused dev to choose from? Where do we stop, just Github, Gitlab and Bitbucket? Or more? The last thing we want is for google to send people off to github as first choice. What can we do to improve our own search rankings? I know the php frontends are bad performers, can we give search engines a more direct route that can be easily linked back to the main frontend? I would note from reading the Gnome wiki on Github that you can't globally turn off pull requests for an organisation, you need to do it for each repo. It would also appear they manually deal with incoming requests to transfer patches over? Ouch. There's two separate groups we need to target here, devs who just want to use our code (Frameworks mostly) and maybe offer the occasional patch, and devs who want to get involved on KDE development. For the former, being easy to find and build is primary. For the latter, not so much as they'll be more motivated to jump through our dev experience hoops, but they still need to find us in the first place and a difficult experience drives too many away. (and no, that's not a good thing, making it hard to get in does not guarantee you only get get smart people, just the stubborn ones). So, a proposal for a trial. Given how tricky it is to build KDE stuff, and we're not sure what impact it will have on linking and google ranking, how about we conduct an experiment. Open a kde_community organisation and only mirror our Tier 1 Frameworks there, seeing as they just need Qt and cmake stuff and so are easy to build and are the thing we most want to share with outside devs. Or schoose a small stable subset of Frameworks. Disable issues and pull requests, add readme's pointing to TechBase for info on how to build and how to submit patches, then sit back and see what the results are in terms of google ranking and code submissions. Perhaps do the same for Gitlab and Bitbucket as well. (We should nab kdecommunity or kde_community on all the hosts asap, regardless of what we do!) Any volunteers, because to be blunt the SysAdmins have enough on their plate in sorting out our own infrastructure! Regardless, we really should work on our own new developer story, both in tooling and documentation. I've started on the docs, but we need to improve the tooling too to make it easier and more convenient. It's a competition we're loosing to other projects that have better new dev experiences. Think of it as a UX problem and lets get to solving it. John. _______________________________________________ kde-community mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-community
