Re: Moving documentation to Git

Thanks for your response. git.php.net and GitHub mirror seems like a perfect option as a current practice with other PHP repositories, yes. Thinking of Git, there shouldn't be anything else to consider anyway, such as GitLab or other custom git repository locations. I understand there are many refactorings required with such step, so its best done by people who know SVN and have all necessary access to those servers, and also understand the importance of such migration. Editing current documentation seems so complex and slow to me, that it is basically impossible to do some useful contributions in some decent time, that's why I'm asking all this in the first place. And going through the bugs.php.net related to docs, there are quite some things to fix in the content... https://github.com/phpdoctest: - wow, that's exactly what is needed yes - contributors and commit history from the SVN should remain - those SVN specific functionalities should all be dropped and replaced by Git ones - languages will cause confusions and probably any refactorings of these also, not to mention concerns and resentments from current translators if something is removed. They could be done as Git branches or possibly separate repositories (that would mean 20+ separate repos only for the docs) and all inactive translations can be also simply removed and not activated with the migration (speaking of Slovenian translation, as an example). In case translators will be able to keep up with the upstream English version of the documentation, that's great. The edit.php.net option: - if it's possible to patch it and update it for using Git, then yes. Otherwise, I would suggest a deprecation and moving the app to the legacy mode as part of the PHP evolution process. - people not used to Git basically won't consider using it, because they have better and simpler editor available over GitHub instead (yes, it's that simple). - people used to edit.php.net probably also patch only very minor things here and there, because patching something bigger is too difficult via such tools As an example, with Dojo Toolkit project there is a livedocs.dojotoolkit.org - similar approach (edits there are committed to the main Git documentation repository in real time). But as time passed by, the editor usage became inactive because it is much much simpler to edit some typo over GitHub editing and forking options. - maintaining "in-house" software used for only minor purposes is very tedious over time.