Retire/transition the wiki?

[dscho]

At https://github.com/git-for-windows/git/wiki, we maintain a wiki that is intended to hold information crucial to the Git for Windows project. We set it up as a wiki to lower the bar of entry so that contributors can make changes quickly and painlessly.

Unfortunately, it also lowers the bar of entry to people whose contributions cannot be welcome.

I cannot recall how often I had to revert/force-push-overwrite misleading, demeaning, and outright vandalizing changes in the past few years, it was that many times. If I had to put a number on it, I'd say roughly 50-150 times in the past two years alone.

That is in stark contrast to the number of really helpful and valuable changes, which were probably more in the one-to-two-dozen range over the same time period.

Here is what I would propose to do, if there is enough agreement that we need to lower the cost of maintenance (at the cost of making it slightly harder to contribute):

1. lock down the wiki so that only users with write access to git-for-windows/git can make changes,
2. merge the wiki into a subdirectory of the Documentation/ directory in git-for-windows/git,
3. replace the pages with links and a short description why the wiki was moved into the main repository

This would give us the benefit of the PR/spam-management tooling which would prevent any vandalized pages ever to reach any users, and thereby drastically reduce any incentive to try doing that in the first place.

Thoughts?

[PhilipOakley]

I'm supportive of the need to reduce the maintenance cost, however my concern would be that we accidentally raise the cost/effort bar for contributions a step too high and that we lose any contributions that may have been forthcoming, and benefits of the consolidated location for documentation.

I'd be happy with a Documentation/Wiki/ sub-directory for holding the wiki.

We'd need a wiki-guide to identify the lower bar of entry so that contributors can make changes quickly and painlessly to this section while still keeping out unwelcome ("unplanned") dross. I guess one rule would be that PRs for the Wiki must be separate from PRs for the rest of the Git-for-Windows project (which still would have it's fairly rigorous reviews).

If the PR process for the wiki contributions goes beyond two rounds of 'corrections' it's probably a non-starter as we get into the "better is the enemy of good-enough" territory. As long as the contribution/PR has an introductory "why" sentence, and a few headings for the sections, and a quick spell check, it should be accepted in the "What I Know Is [wiki]" spirit, as long as it relates to Git for Windows.

[dscho]

I'd be happy with a Documentation/Wiki/ sub-directory for holding the wiki.

I am thinking more about a Documentation/windows/ that is linked from README.md.

And no, I don't like the idea of raising the bar for contributions, but realistically we don't get many in the first place, and those can easily be PRs that are created via web editor.

[PhilipOakley]

I am thinking more about a Documentation/windows/ that is linked from README.md.

Sounds reasonable. No objections.

I don't like the idea of raising the bar for contributions, but realistically we don't get many in the first place, and those can easily be PRs that are created via web editor.

I just felt it was worth spelling out (that it would be an on-point wiki), so that all sides treat the PRs in the appropriate manor without any mission creep. E.g. in a Guidelines.md in that same directory.

[goyalyashpal]

my take can be naive as i have not maintained any project personally.

but yeah, this possibility is always there in wikis. the pop-wikis or SE-network have good enough traffic and good enough amount of ppl / moderators to keep vandalisms away. but that ain't the case with git repos.

I guess one rule would be that PRs for the Wiki must be separate from PRs for the rest of the Git-for-Windows project (which still would have it's fairly rigorous reviews).
- @ PhilipOakley at #4543 (comment)

the separate dir was okay, but yeah, along with above point, it would also mess with the project commit-history. so, how about creating separate repo?
a separate repo just sounds like a big deal, but actually it's much better than a wiki in its reachability imo. it can even be configured to be rendered as a static site (which would likely be a one time investment).