Wiki RFC: Redirects, swarm tactics, etc.
So I've finished with pretty much all of the edits I had in mind for the wiki, but before I ride off into the sunset for a while, I wanted to toss out a few ideas. 1. Do we want some kind of guideline on redirects for the wiki? Some stable "interface" pages to the main site might be good, but beyond that, I think minimizing redirects makes sense in this use case. 2. There's still a lot of old/missing content on the wiki, and much of it requres a good sense of where the code is at. Also, it might be too overwhelming for one person to work in depth on more than a few pages at this point. I feel like a semi-coordinated swarm of editing might be the best bet for further improvements. I was picturing a table of all relevant pages, then people could adopt one or two to work on, then strike/delete a record once that page is finished. Any thoughts? 3. There are actually a few more fixes to the theme code at the head of my bitbucket repo (and also branches for 2 different Moinmoin upgrade paths). I'm cool with keeping the theme code for the near future; if and when we move it onto WineHQ's git server though, just let me know so I can note that I'm not upstream anymore. 4. Finally, spammers... they keep coming... and they're getting smarter. We can mostly stalemate them with the regex filter, but it blocks legit edits too sometimes (in very annoying fashion). In fact, I think there are a few of them that have learned to turn the filter against us by completely wiping pages with false positives so we can't revert the page. Are there any relatively easy things we could do to cut the spam? I don't know, but it's possible the newer version of Moinmoin has more potent anti-spam tools. -Kyle
On Thu, Aug 1, 2013 at 11:03 PM, Kyle Auble <kauble(a)lavabit.com> wrote:
So I've finished with pretty much all of the edits I had in mind for the wiki, but before I ride off into the sunset for a while, I wanted to toss out a few ideas. .. 2. There's still a lot of old/missing content on the wiki, and much of it requres a good sense of where the code is at. Also, it might be too overwhelming for one person to work in depth on more than a few pages at this point. I feel like a semi-coordinated swarm of editing might be the best bet for further improvements. I was picturing a table of all relevant pages, then people could adopt one or two to work on, then strike/delete a record once that page is finished. Any thoughts?
I'll help, if you have a list of pages that you need edited. -Austin
Am 02.08.2013 08:13, schrieb Austin English:
On Thu, Aug 1, 2013 at 11:03 PM, Kyle Auble <kauble(a)lavabit.com> wrote:
So I've finished with pretty much all of the edits I had in mind for the wiki, but before I ride off into the sunset for a while, I wanted to toss out a few ideas. .. 2. There's still a lot of old/missing content on the wiki, and much of it requres a good sense of where the code is at. Also, it might be too overwhelming for one person to work in depth on more than a few pages at this point. I feel like a semi-coordinated swarm of editing might be the best bet for further improvements. I was picturing a table of all relevant pages, then people could adopt one or two to work on, then strike/delete a record once that page is finished. Any thoughts?
I'll help, if you have a list of pages that you need edited.
+1
I've just started looking at the Wiki myself. There's a lot of outdated stuff on there and it needs a lot of attention. There's little hope of me helping with anything related to the actual programming but I'm willing to help with other stuff. On 02/08/13 07:03, Kyle Auble wrote:
So I've finished with pretty much all of the edits I had in mind for the wiki, but before I ride off into the sunset for a while, I wanted to toss out a few ideas.
1. Do we want some kind of guideline on redirects for the wiki? Some stable "interface" pages to the main site might be good, but beyond that, I think minimizing redirects makes sense in this use case.
2. There's still a lot of old/missing content on the wiki, and much of it requres a good sense of where the code is at. Also, it might be too overwhelming for one person to work in depth on more than a few pages at this point. I feel like a semi-coordinated swarm of editing might be the best bet for further improvements. I was picturing a table of all relevant pages, then people could adopt one or two to work on, then strike/delete a record once that page is finished. Any thoughts?
3. There are actually a few more fixes to the theme code at the head of my bitbucket repo (and also branches for 2 different Moinmoin upgrade paths). I'm cool with keeping the theme code for the near future; if and when we move it onto WineHQ's git server though, just let me know so I can note that I'm not upstream anymore.
4. Finally, spammers... they keep coming... and they're getting smarter. We can mostly stalemate them with the regex filter, but it blocks legit edits too sometimes (in very annoying fashion). In fact, I think there are a few of them that have learned to turn the filter against us by completely wiping pages with false positives so we can't revert the page. Are there any relatively easy things we could do to cut the spam? I don't know, but it's possible the newer version of Moinmoin has more potent anti-spam tools.
-Kyle
On Fri, 02 Aug 2013 01:03:34 -0500 Kyle Auble <kauble(a)lavabit.com> wrote:
3. There are actually a few more fixes to the theme code at the head of my bitbucket repo (and also branches for 2 different Moinmoin upgrade paths).
By any chance do any of those fixes/branches take care of http://bugs.winehq.org/show_bug.cgi?id=28578? That bug stops me from touching any page with preformatted text on it, specifically the FAQ, which is the one page I use most often and need to be able to update.
Are there any relatively easy things we could do to cut the spam?
From http://bugs.winehq.org/show_bug.cgi?id=33470#c6: disable new user registration and force users to manually request accounts.
-- Rosanne DiMesio <dimesio(a)earthlink.net>
Thanks everyone, I've created a table of all of the pages that seemed relevant at http://wiki.winehq.org/WebContentTasks/WikiParty. I put down details on that page and its parent instead of cluttering up this email. On 08/02/2013 06:49 AM, Rosanne DiMesio wrote:
By any chance do any of those fixes/branches take care of http://bugs.winehq.org/show_bug.cgi?id=28578? That bug stops me from touching any page with preformatted text on it, specifically the FAQ, which is the one page I use most often and need to be able to update. As for the preformatted text issue, I actually just tried a few things in the sandbox and you can cancel the exorcism. I'm seeing it too. It seems to be specific to the GUI editor so if you don't mind using the text editor in the short term, that won't choke on the preformatted text. I'll post my thoughts in more detail on the bug report. From http://bugs.winehq.org/show_bug.cgi?id=33470#c6: disable new user registration and force users to manually request accounts. Then for the spammers, I'm with the discussion in the link. We have a lot of valid links to resources, and restricting all external sites would cripple the wiki much more than the spammers, but having to request an account sounds reasonable to me. I doubt someone familiar with Wine and interested enough to edit the wiki would be discouraged by a short confirmation process.
-Kyle
participants (5)
-
André Hentschel -
Austin English -
Ken Sharp -
Kyle Auble -
Rosanne DiMesio