There is a lot of potential in Wikisource, but it depends heavily on the ProofreadPage extension and it has several bugs that are reported but don't get fixed.
ThomasV is the main developer and perhaps he is the only maintainer? It would be in the interest of the Wikimedia Foundation to assign a salaried developer or two into developing a more robust framework for Wikisource, either by improving the existing extension or by integrating some or all of its functionality into MediaWiki proper.
People everywhere have a need to make some PDF (or Djvu) document available on a website, page by page, with the ability to add categories and talk pages. This ability is what the ProofreadPage extension adds to MediaWiki. In my mind, it is as essential as the support for uploading JPEG images and automatically generating thumbnails. Adding multipage documents to a wiki should be a far more common need than adding mathematical equations.
--- On Mon, 6/28/10, Lars Aronsson lars@aronsson.se wrote:
From: Lars Aronsson lars@aronsson.se Subject: [Wikisource-l] Wikisource bugs To: "Wikisource" wikisource-l@lists.wikimedia.org, "Wikimedia developers" wikitech-l@lists.wikimedia.org Date: Monday, June 28, 2010, 4:22 PM There is a lot of potential in Wikisource, but it depends heavily on the ProofreadPage extension and it has several bugs that are reported but don't get fixed.
ThomasV is the main developer and perhaps he is the only maintainer? It would be in the interest of the Wikimedia Foundation to assign a salaried developer or two into developing a more robust framework for Wikisource, either by improving the existing extension or by integrating some or all of its functionality into MediaWiki proper.
People everywhere have a need to make some PDF (or Djvu) document available on a website, page by page, with the ability to add categories and talk pages. This ability is what the ProofreadPage extension adds to MediaWiki. In my mind, it is as essential as the support for uploading JPEG images and automatically generating thumbnails. Adding multipage documents to a wiki should be a far more common need than adding mathematical equations.
Are you thinking of some bugs in paticular? I would like to see what has already been said at bugzilla if you have the numbers.
Birgitte SB
On 06/28/2010 11:25 PM, Birgitte SB wrote:
Are you thinking of some bugs in paticular? I would like to see what has already been said at bugzilla if you have the numbers.
Force now to look, I'm surprised to find there really are only a few reported bugs in the ProofreadPage extension.
Some of the bugs I've long waited for to be fixed are instead in the PDF/Djvu page extraction, which is not part of ProofreadPage, https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 https://bugzilla.wikimedia.org/show_bug.cgi?id=23326
I have a long time frustration with how over-complicated ProofreadPage is with its extra namespaces, new tags and dozens of parameters that each newcomer needs to learn, and it spilled over yesterday when I registered https://bugzilla.wikimedia.org/show_bug.cgi?id=24168
If there are more bugs, they should be reported in Bugzilla. But what also really needs to be done is to reconsider if ProofreadPage really needs to be all this complicated. Maybe I should register that as a bug?
I wish to clarify that my first post should not be read as a personal attack on ThomasV. We all want Wikisource to improve and grow, and we're working together towards that goal.
Lars Aronsson a écrit :
Some of the bugs I've long waited for to be fixed are instead in the PDF/Djvu page extraction, which is not part of ProofreadPage, https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 https://bugzilla.wikimedia.org/show_bug.cgi?id=23326
A patch has been proposed a long time ago for bug 21526. I never applied it because it's a perl-like regexp, and I am not familiar enough with this syntax.
but I guess it would not be difficult to have this commited by someone else.
This email highlighted and remind me of a couple of issues,
1. The indexing functionality and how it fails for transcluded pages; which is integral to ProofreadPage when it transcludes working pages into the main namespace for display. https://bugzilla.wikimedia.org/show_bug.cgi?id=18861 (thanks to MZMcBride for helping me track this down)
2. The support around djvu files in general, which is improved, though still lacking in the <gallery> extension, see https://bugzilla.wikimedia.org/show_bug.cgi?id=8480
Both of which have an impact for WS, though not exclusive to the site.
Regards, sDrewth
On 28 Jun 2010 at 23:22, Lars Aronsson wrote:
There is a lot of potential in Wikisource, but it depends heavily on the ProofreadPage extension and it has several bugs that are reported but don't get fixed.
ThomasV is the main developer and perhaps he is the only maintainer? It would be in the interest of the Wikimedia Foundation to assign a salaried developer or two into developing a more robust framework for Wikisource, either by improving the existing extension or by integrating some or all of its functionality into MediaWiki proper.
People everywhere have a need to make some PDF (or Djvu) document available on a website, page by page, with the ability to add categories and talk pages. This ability is what the ProofreadPage extension adds to MediaWiki. In my mind, it is as essential as the support for uploading JPEG images and automatically generating thumbnails. Adding multipage documents to a wiki should be a far more common need than adding mathematical equations.
-- Lars Aronsson (lars@aronsson.se) Aronsson Datateknik - http://aronsson.se
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
*There* is a wish for an possible enhancement. It would be nice to have another state,m let's call it partly proofread once. In the german language WS there a lot of magazines. The typically end in the middle of the page, or there are several articles on one page. It would be nice to flag if there are proofreaded parts on this page.
*The* following bug shall be added to this list here, Wikisource: IPs unable to flag articles as "proofread" https://bugzilla.wikimedia.org/show_bug.cgi?id=20812
There have been still long discussions with no solution Especially teh comment from --- Comment #28 from John Mark Vandenberg jayvdb@gmail.com 2009-11-19 15:31:21 UTC --- Please provide unified diffs using "diff -ur old/ new/"
More fundamentally, I think it is necessary for the Proofread Page extension to not include access control. It should probably use the userCan hook, and let another extension implement access control.
Also should be added, even admins aren't able to set pages to proofread twice. In the de:ws we are converting, already proofread twice projects to this extension, because the method with the two additional namespaces is handsome. But it is an awfull work to go through the already done steps again.
*There* is a bug, with zooming of the scans in PR2, the scrollbar vanishes, and the picture itself is growing ore reducing itself - uninterruptable-
greetings
2010/6/29 Billinghurst billinghurst@gmail.com
This email highlighted and remind me of a couple of issues,
- The indexing functionality and how it fails for transcluded pages; which
is integral to ProofreadPage when it transcludes working pages into the main namespace for display. https://bugzilla.wikimedia.org/show_bug.cgi?id=18861 (thanks to MZMcBride for helping me track this down)
- The support around djvu files in general, which is improved, though
still lacking in the <gallery> extension, see https://bugzilla.wikimedia.org/show_bug.cgi?id=8480
Both of which have an impact for WS, though not exclusive to the site.
Regards, sDrewth
On 28 Jun 2010 at 23:22, Lars Aronsson wrote:
There is a lot of potential in Wikisource, but it depends heavily on the ProofreadPage extension and it has several bugs that are reported but don't get fixed.
ThomasV is the main developer and perhaps he is the only maintainer? It would be in the interest of the Wikimedia Foundation to assign a salaried developer or two into developing a more robust framework for Wikisource, either by improving the existing extension or by integrating some or all of its functionality into MediaWiki proper.
People everywhere have a need to make some PDF (or Djvu) document available on a website, page by page, with the ability to add categories and talk pages. This ability is what the ProofreadPage extension adds to MediaWiki. In my mind, it is as essential as the support for uploading JPEG images and automatically generating thumbnails. Adding multipage documents to a wiki should be a far more common need than adding mathematical equations.
-- Lars Aronsson (lars@aronsson.se) Aronsson Datateknik - http://aronsson.se
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
2010/6/29 Michael Jörgens joergens.mic@googlemail.com:
The following bug shall be added to this list here, Wikisource: IPs unable to flag articles as "proofread" https://bugzilla.wikimedia.org/show_bug.cgi?id=20812 There have been still long discussions with no solution
It is absolutely neccessary to solve this problem. It is not acceptable that a dev is ignoring the community consensus. We urgently need other/better devs. At the de WS Summit at Skillshare in Lüneburg WMF Board member Ting Chen has agreed that a better communication between devs and communities is an important issue.
Greetings, Dr. Klaus Graf administrator de WS
--- On Tue, 6/29/10, Klaus Graf klausgraf@googlemail.com wrote:
From: Klaus Graf klausgraf@googlemail.com Subject: Re: [Wikisource-l] [Wikitech-l] Wikisource bugs To: "discussion list for Wikisource, the free library" wikisource-l@lists.wikimedia.org Date: Tuesday, June 29, 2010, 8:40 AM 2010/6/29 Michael Jörgens joergens.mic@googlemail.com:
The following bug shall be added to this list here,
Wikisource: IPs unable
to flag articles as "proofread" https://bugzilla.wikimedia.org/show_bug.cgi?id=20812 There have been still long discussions with no
solution
It is absolutely neccessary to solve this problem. It is not acceptable that a dev is ignoring the community consensus. We urgently need other/better devs. At the de WS Summit at Skillshare in Lüneburg WMF Board member Ting Chen has agreed that a better communication between devs and communities is an important issue.
History for those on Wikitech-l
The bridge between ThomasV and de.WS has been burnt.
The resolution of this particular bug, which is dear to de.WS and ambivalent outside of de.WS, will absolutely require a new dev taking interest.
I hope we can avoid rehashing the all the could-a, should-a, would-a again and focus on what can be accomplished from where things stand.
Birgitte SB
Just to clarify, I disagree with "The bridge between ThomasV and de.WS has been burnt."
We have strong controverse discussions and still different viewpoints - unfortunately there is no movement of ThomasV in any of his statements. But we must use ThomasV work and find ways to get better solutions.
One of our big problems is, that there is neihter a js-programmer nor an php programmer in our community to find better implementations or workarounds for the problems.
And I agree to the *content* of Dr. Klaus Graf statements.
But I hope that we can stay with the technical arguments and find solutions.
2010/6/29 Birgitte SB birgitte_sb@yahoo.com
--- On Tue, 6/29/10, Klaus Graf klausgraf@googlemail.com wrote:
From: Klaus Graf klausgraf@googlemail.com Subject: Re: [Wikisource-l] [Wikitech-l] Wikisource bugs To: "discussion list for Wikisource, the free library" <
wikisource-l@lists.wikimedia.org>
Date: Tuesday, June 29, 2010, 8:40 AM 2010/6/29 Michael Jörgens joergens.mic@googlemail.com:
The following bug shall be added to this list here,
Wikisource: IPs unable
to flag articles as "proofread" https://bugzilla.wikimedia.org/show_bug.cgi?id=20812 There have been still long discussions with no
solution
It is absolutely neccessary to solve this problem. It is not acceptable that a dev is ignoring the community consensus. We urgently need other/better devs. At the de WS Summit at Skillshare in Lüneburg WMF Board member Ting Chen has agreed that a better communication between devs and communities is an important issue.
History for those on Wikitech-l
The bridge between ThomasV and de.WS has been burnt.
The resolution of this particular bug, which is dear to de.WS and ambivalent outside of de.WS, will absolutely require a new dev taking interest.
I hope we can avoid rehashing the all the could-a, should-a, would-a again and focus on what can be accomplished from where things stand.
Birgitte SB
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
2010/6/29 Michael Jörgens joergens.mic@googlemail.com
Just to clarify, I disagree with "The bridge between ThomasV and de.WS has been burnt."
We have strong controverse discussions and still different viewpoints - unfortunately there is no movement of ThomasV in any of his statements. But we must use ThomasV work and find ways to get better solutions.
One of our big problems is, that there is neihter a js-programmer nor an php programmer in our community to find better implementations or workarounds for the problems.
Just a brief general comment: how much I'll would like a single, large, commons-like multilengual wikisource... shared tools, shared templates, shared tricks, shared js, php, python experts, working together ... no more troubles with multilengual books.... no more Iwpage templates and other difficult interlanguage transclusions... :-(
Alex
Hi.
The following bug shall be added to this list here, Wikisource: IPs unable to flag articles as "proofread" https://bugzilla.wikimedia.org/show_bug.cgi?id=20812 There have been still long discussions with no solution
It is absolutely neccessary to solve this problem. It is not acceptable that a dev is ignoring the community consensus. We urgently need other/better devs.
(...) The bridge between ThomasV and de.WS has been burnt. The resolution of this particular bug, which is dear to de.WS and ambivalent outside of de.WS, will absolutely require a new dev taking interest. I hope we can avoid rehashing the all the could-a, should-a, would-a again and focus on what can be accomplished from where things stand.
I'd like to add that there may be a community consensus on this subject in de:ws . But in fr:ws, we agree with ThomasV that allowing IPs to proofread can be more dangerous than useful (but I know there are fewer IPs on fr:ws than on de:ws). Speaking of consensus is not fair, regarding the debates that Birgitte refered to.
Best wishes,
--- On Tue, 6/29/10, Hélène Pedrosa-Masson edhral@free.fr wrote:
From: Hélène Pedrosa-Masson edhral@free.fr Subject: Re: [Wikisource-l] [Wikitech-l] Wikisource bugs To: "discussion list for Wikisource, the free library" wikisource-l@lists.wikimedia.org Date: Tuesday, June 29, 2010, 12:44 PM Hi.
The following bug shall be added to this list
here, Wikisource:
IPs unable to flag articles as "proofread" https://bugzilla.wikimedia.org/show_bug.cgi?id=20812 There have been still long discussions with no
solution
It is absolutely neccessary to solve this problem.
It is not
acceptable that a dev is ignoring the community
consensus.
We urgently need other/better devs.
(...) The bridge between ThomasV and de.WS has been
burnt.
The resolution of this particular bug, which is dear
to de.WS and
ambivalent outside of de.WS, will absolutely require a
new dev
taking interest. I hope we can avoid rehashing the all the could-a,
should-a, would-a
again and focus on what can be accomplished from where
things stand.
I'd like to add that there may be a community consensus on this subject in de:ws . But in fr:ws, we agree with ThomasV that allowing IPs to proofread can be more dangerous than useful (but I know there are fewer IPs on fr:ws than on de:ws). Speaking of consensus is not fair, regarding the debates that Birgitte refered to.
Just to clarify. The bug discussion progressed into making the issue configurable.
This would mean fr.WS would configure things to not allow IPs (desired to maintain things the same as current local set-up) and de.WS to allow IPs (desired to restore a historical local set-up). This is why I described those outside of de.WS as ambivilent (it does not matter very much to them), they will be able to keep their desired local set-up with or without the bug resolved.
Birgitte SB
I (or we on de.ws) have no problem with a configurable system, to allow or forbid access rights to users or group of users. And nobody of us has a problem with John Vandenbergs proposal.
I think the tool shall respect, the consensus of the community, not a community the rules of a single tool.
If there is an agreement in the community to exclude IP's, it's ok when a skilled person (admin / beaurokrat) of the community can set the rules / access rights to do so.
Vandenbergs proposal to do this with the ''user can hook'', if this is the correct solution to get everyone happy, please help us all to implement this. If there is a better ( but I don't think so - with my little technikal knowledge) technical solution available for doing that in a mediawiki conform way, let's do it that way.
Hi Alex, I support your wishes and ideas, but I think I'm a little bit more pessimistic on that issue. Commons works (but not more), because it is a big repository of single media, therefore it's easier to deal with, than with books and common macros. But if there a ways to improve and harmonise the way of working, lets give it a try. Especially ThomasV extension is an excellent piece to show that way of working together.
2010/6/29 Birgitte SB birgitte_sb@yahoo.com
--- On Tue, 6/29/10, Hélène Pedrosa-Masson edhral@free.fr wrote:
From: Hélène Pedrosa-Masson edhral@free.fr Subject: Re: [Wikisource-l] [Wikitech-l] Wikisource bugs To: "discussion list for Wikisource, the free library" <
wikisource-l@lists.wikimedia.org>
Date: Tuesday, June 29, 2010, 12:44 PM Hi.
The following bug shall be added to this list
here, Wikisource:
IPs unable to flag articles as "proofread" https://bugzilla.wikimedia.org/show_bug.cgi?id=20812 There have been still long discussions with no
solution
It is absolutely neccessary to solve this problem.
It is not
acceptable that a dev is ignoring the community
consensus.
We urgently need other/better devs.
(...) The bridge between ThomasV and de.WS has been
burnt.
The resolution of this particular bug, which is dear
to de.WS and
ambivalent outside of de.WS, will absolutely require a
new dev
taking interest. I hope we can avoid rehashing the all the could-a,
should-a, would-a
again and focus on what can be accomplished from where
things stand.
I'd like to add that there may be a community consensus on this subject in de:ws . But in fr:ws, we agree with ThomasV that allowing IPs to proofread can be more dangerous than useful (but I know there are fewer IPs on fr:ws than on de:ws). Speaking of consensus is not fair, regarding the debates that Birgitte refered to.
Just to clarify. The bug discussion progressed into making the issue configurable.
This would mean fr.WS would configure things to not allow IPs (desired to maintain things the same as current local set-up) and de.WS to allow IPs (desired to restore a historical local set-up). This is why I described those outside of de.WS as ambivilent (it does not matter very much to them), they will be able to keep their desired local set-up with or without the bug resolved.
Birgitte SB
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
On Tue, Jun 29, 2010 at 11:33 PM, Michael Jörgens joergens.mic@googlemail.com wrote:
The following bug shall be added to this list here, Wikisource: IPs unable to flag articles as "proofread" https://bugzilla.wikimedia.org/show_bug.cgi?id=20812
If there are no disagreements with my comment on that bug, I now have time to develop this.
-- John Vandenberg
Here is my answer to the statements made recently.
* For those who are not familiar with the issue, I am the main developer of ProofreadPage, a Mediawiki software extension that allows Wikisource users to proofread a page of text by comparing it to its scanned source. This extension also manages book metadata and citation information, and it imposes a very basic processing workflow, where a page must have been checked by two different users in order to reach its final state. [see here : http://en.wikisource.org/wiki/Help:Page_Status]
* This extension has been introduced four years ago. Since then, more than 350000 pages have been proofread with it, and more than 120000 pages have been double-checked. By now, between 500 and 1000 pages are being proofread every day at Wikisource. These figures are growing rapidly, and we can reasonably expect that Wikisource will become more active than Project Gutenberg's Distributed Proofreaders in the coming years.
* A few de.ws admins have requested that the ProofreadPage extension be modified, in order to allow anonymous users to mark pages as "proofread". It is very important to understand that they do not request only that : They want any user, anonymous not, to be able to set any page to "validated" (quality level 4), no matter if it has passed through the "proofread" stage (quality level 3). And this is indeed what would happen if IPs were allowed to mark a page as "proofread". This would break the "two proofreaders" rule.
* As a matter of fact, these de.ws admins are not opposed to the "two proofreaders" rule. However, they want this rule to be enforced by themselves, not by software. Indeed, before the introduction of ProofreadPage, the "two proofreaders" rule was enforced at de.ws by the community, and this rule did not exist at other wikisources.
* The "two proofreaders" rule that is built into the software is not meant to be robust ; it is very easy to circumvent by using sockpuppets. And its goal is not to prevent vandalism, as is sometimes stated. No, the goal of this software restriction is to ensure that various users, who do not necessarily read the rules, or who do not interpret them in the same way, share a common interpretation of the quality levels. Its goal is to make their meaning unambiguous.
* I do not think that the "two proofreaders" rule can be enforced in the long run by a wiki community, without software. This rule has been enforced at de.ws for some time, because it was a small community, where most users knew themselves, and where rules were very strictly observed (my goal is not to spread stereotypes about the Germans; they are very proud about their superior quality standards). However, such a level of organization and rule enforcement cannot be achieved at other wikis, because they are much more lax and larger communities, with less rules, with users who do not take time to read the rules, with users who sometimes disagree with rules, and where most users do not like to play the police. In the long run, enforcing that rule will become impossible at de.ws too.
* In a lax community, where users do not always read the rules before participating, if a rule is not clear or ambiguous, then users start to develop their own interpretations of it. In this context, if any user is allowed to set any page to quality level 4, no matter if that page has been proofread before, then users will start to have diverging interpretations of the meaning of q3 and q4. For example, some of them will decide to use q3 for proofreading, and q4 for formatting. This is not a thought experiment: It already happened at fr.ws, with our previous proofreading system based on icons. And you cannot blame users for that : it is very intuitive to think that q3 means "unfinished", when there is another level called "q4".
* In contrast, if software does not let you reach q4 but only q3, no matter how well you proofread and format a page, then it does not make sense to believe that you are supposed to leave some part of the formatting work for later, for the person who will be doing q4. The only interpretation that makes sense is that you should do as much proofreading and formatting work as you can. And if you use a sockpuppet in order to reach q4, then you _know_ that you're doing something you're not supposed to do.
* Thus, removing the "two proofreaders" rule from ProofreadPage would spell the end of the current proofreading workflow. Again, this is not a thought experiment, but something that already happened at fr.ws with our previous system. Once a wiki decides to enable such an option, we will see users making diverging interpretations of the quality levels, and the pages that were previously validated by two users will be in the same category as pages validated by a single user. This would be a complete lack of respect for the validation work that has been accomplished so far.
* For this reason, I will never allow such a change to be made to ProofreadPage. I do design and maintain this extension by listening to the requests of users, and I do implement most of the features they request, or add patches submitted by other users. However, when a request is so blatantly contradicting the purpose of the tool, I believe that I have the right to refuse it.
* Please note that I am not opposed to IPs, and my goal is not to discriminate them. And I would certainly allow IPs to mark pages as "proofread", if we could find a way to do this in a way that does not hurt the "two proofreaders" rule. I even proposed to allow pages status to be modified by a whitelist of static IPs, but my proposal was ignored.
* As a matter of fact, there are various other things that anonymous users are not allowed to do at the Foundation. One restriction that is particularly relevant for Wikisource is the fact that IPs are not allowed to upload scans. This implies that they are not allowed to start a new proofreading project. Strangely, this intolerable discrimination does not seem to hurt anyone at de.ws. If their fight is really about the rights of IPs, why don't they complain about that?
* More generally, I do not feel comfortable when someone pretends to speak for a category of people who do not express themselves. When a minority is silent, you can put any words in their mouth. According to Michael Joergens, these anonymous users are scared of getting registered and of giving away their email addresses, and he is mandated to speak for them. But how can we check their existence, how can we check how many they are, if they refuse to be identified ?
Finally, several statements have been made in the previous messages, that are wrong or misleading :
* Firstly, it was written that de.ws _must_ use the ProofreadPage extension. This is not true. There are other similar proofreading tools that have been developed at de.ws, and these tools are still used today. You are free to use or to develop whatever you want.
* Secondly, it is false to claim that there is a consensus at de.ws, in favor of allowing IPs to mark pages as "Proofread". The statement made in this mailing list, about the existence of such a consensus, has been questioned shortly after in the de.wikisource Scriptorium. So, if Klaus Graf wants to speak in the name of the de.ws community, he should ask them first. Eight months ago I suggested that a vote be organized at de.ws, on that question; instead of that, the same group of admins held a vote in order to have me desysoped (and they lost it).
* Thirdly, if the de.wikisource community decides, by vote or by consensus, that they want IPs to be allowed to change the quality status of pages, they can do this without destroying ProofreadPage. They just need to step out of the ProofreadPage quality system, and restore their previous system in place of it. I am willing to explain how to do this to any technically skilled person. Note that I already made the same proposal in bugzilla 8 months ago.
I apologize for the length of my answer. I wish to thank those who have had the patience to read this entire post.
Thomas
ThomasV has written a bulk of nonsense. He is clearly lying when asserting that only a few admins are against his misuse of his dev privileges.
Some users have tried to desysop ThomasV because of his inacceptable and the project damaging behaviour in 2009:
http://de.wikisource.org/w/index.php?title=Wikisource:Administratoren&ol...
8 users were pro admin rights for Thomas V, 7 against. Please NOTE that NONE user has defended the IP decision but some have articulated that they are opposing. Here are 2 pro-admin votes:
Finanzer (our de WS 'crat): "was aber nicht heissen soll, dass ich Thomas' Verhalten gutheisse, im Gegenteil" (i.e. he has clearly said that ThomasV's behaviour was bad).
Dorades: "Was das eigentliche Problem, die Änderung von Bearbeitungsständen durch IPs, betrifft, stimme ich mit der Community überein und spreche mich dagegen aus." This means that in the eyes of Dorades the community were unanimously against the ThomasV IP-decision.
It was and is useless to argue with ThomasV. I see a strong consensus in the WS community that the WS and not ThomasV has to make the core decisions.
Klaus Graf
Klaus Graf wrote:
... has written a bulk of nonsense. He is clearly lying when
This kind of personal attack is never acceptable, and not helpful to this particular issue. The style is, however, typical of Klaus Graf, and he has not shown any sign of improving in the years that I have seen him on various mailing lists. Can we please have him removed from this discussion?
I don't know if there is an sense to reply to this mail, because is only a copy of the same boring discussion we had several times. And which can be broken down to the sarcastic sentence. "I the developer know what is good for the world, and everybody has to follow my will''. If he wants to overrule his own community, or there is a consensus there to have these hard coded rules, in a configurable system he can set the flags accordingly. If an other community has more confidence in their community and don't want the hard rules, set the flags to the according values and everybody (or all except one) will be happy.
And you can be shure that there is a broad consensus by the real active people to get the ip's editing allowed. And the second point he always forgets to mention, is that he make us a lot of work to transfer older projects to this extension. He is not willing to give the right to set pages which have been validated before to the validated state by transferring it to his extension. Even Admins are excluded from doing that.
Sorry for beeing a little bit sarcastic,but I think i've (we) had this discussion with ThomasV now 4 or 5 times. And I don't find a way to get a good solution, together with him.
Greetings
2010/7/1 ThomasV thomasV1@gmx.de
Here is my answer to the statements made recently.
- For those who are not familiar with the issue, I am the main
developer of ProofreadPage, a Mediawiki software extension that allows Wikisource users to proofread a page of text by comparing it to its scanned source. This extension also manages book metadata and citation information, and it imposes a very basic processing workflow, where a page must have been checked by two different users in order to reach its final state. [see here : http://en.wikisource.org/wiki/Help:Page_Status]
- This extension has been introduced four years ago. Since then, more
than 350000 pages have been proofread with it, and more than 120000 pages have been double-checked. By now, between 500 and 1000 pages are being proofread every day at Wikisource. These figures are growing rapidly, and we can reasonably expect that Wikisource will become more active than Project Gutenberg's Distributed Proofreaders in the coming years.
- A few de.ws admins have requested that the ProofreadPage extension
be modified, in order to allow anonymous users to mark pages as "proofread". It is very important to understand that they do not request only that : They want any user, anonymous not, to be able to set any page to "validated" (quality level 4), no matter if it has passed through the "proofread" stage (quality level 3). And this is indeed what would happen if IPs were allowed to mark a page as "proofread". This would break the "two proofreaders" rule.
- As a matter of fact, these de.ws admins are not opposed to the
"two proofreaders" rule. However, they want this rule to be enforced by themselves, not by software. Indeed, before the introduction of ProofreadPage, the "two proofreaders" rule was enforced at de.ws by the community, and this rule did not exist at other wikisources.
- The "two proofreaders" rule that is built into the software is
not meant to be robust ; it is very easy to circumvent by using sockpuppets. And its goal is not to prevent vandalism, as is sometimes stated. No, the goal of this software restriction is to ensure that various users, who do not necessarily read the rules, or who do not interpret them in the same way, share a common interpretation of the quality levels. Its goal is to make their meaning unambiguous.
- I do not think that the "two proofreaders" rule can be enforced
in the long run by a wiki community, without software. This rule has been enforced at de.ws for some time, because it was a small community, where most users knew themselves, and where rules were very strictly observed (my goal is not to spread stereotypes about the Germans; they are very proud about their superior quality standards). However, such a level of organization and rule enforcement cannot be achieved at other wikis, because they are much more lax and larger communities, with less rules, with users who do not take time to read the rules, with users who sometimes disagree with rules, and where most users do not like to play the police. In the long run, enforcing that rule will become impossible at de.ws too.
- In a lax community, where users do not always read the rules before
participating, if a rule is not clear or ambiguous, then users start to develop their own interpretations of it. In this context, if any user is allowed to set any page to quality level 4, no matter if that page has been proofread before, then users will start to have diverging interpretations of the meaning of q3 and q4. For example, some of them will decide to use q3 for proofreading, and q4 for formatting. This is not a thought experiment: It already happened at fr.ws, with our previous proofreading system based on icons. And you cannot blame users for that : it is very intuitive to think that q3 means "unfinished", when there is another level called "q4".
- In contrast, if software does not let you reach q4 but only q3, no
matter how well you proofread and format a page, then it does not make sense to believe that you are supposed to leave some part of the formatting work for later, for the person who will be doing q4. The only interpretation that makes sense is that you should do as much proofreading and formatting work as you can. And if you use a sockpuppet in order to reach q4, then you _know_ that you're doing something you're not supposed to do.
- Thus, removing the "two proofreaders" rule from
ProofreadPage would spell the end of the current proofreading workflow. Again, this is not a thought experiment, but something that already happened at fr.ws with our previous system. Once a wiki decides to enable such an option, we will see users making diverging interpretations of the quality levels, and the pages that were previously validated by two users will be in the same category as pages validated by a single user. This would be a complete lack of respect for the validation work that has been accomplished so far.
- For this reason, I will never allow such a change to be made to
ProofreadPage. I do design and maintain this extension by listening to the requests of users, and I do implement most of the features they request, or add patches submitted by other users. However, when a request is so blatantly contradicting the purpose of the tool, I believe that I have the right to refuse it.
- Please note that I am not opposed to IPs, and my goal is not to
discriminate them. And I would certainly allow IPs to mark pages as "proofread", if we could find a way to do this in a way that does not hurt the "two proofreaders" rule. I even proposed to allow pages status to be modified by a whitelist of static IPs, but my proposal was ignored.
- As a matter of fact, there are various other things that anonymous
users are not allowed to do at the Foundation. One restriction that is particularly relevant for Wikisource is the fact that IPs are not allowed to upload scans. This implies that they are not allowed to start a new proofreading project. Strangely, this intolerable discrimination does not seem to hurt anyone at de.ws. If their fight is really about the rights of IPs, why don't they complain about that?
- More generally, I do not feel comfortable when someone pretends to
speak for a category of people who do not express themselves. When a minority is silent, you can put any words in their mouth. According to Michael Joergens, these anonymous users are scared of getting registered and of giving away their email addresses, and he is mandated to speak for them. But how can we check their existence, how can we check how many they are, if they refuse to be identified ?
Finally, several statements have been made in the previous messages, that are wrong or misleading :
- Firstly, it was written that de.ws _must_ use the ProofreadPage
extension. This is not true. There are other similar proofreading tools that have been developed at de.ws, and these tools are still used today. You are free to use or to develop whatever you want.
- Secondly, it is false to claim that there is a consensus at de.ws, in
favor of allowing IPs to mark pages as "Proofread". The statement made in this mailing list, about the existence of such a consensus, has been questioned shortly after in the de.wikisource Scriptorium. So, if Klaus Graf wants to speak in the name of the de.ws community, he should ask them first. Eight months ago I suggested that a vote be organized at de.ws, on that question; instead of that, the same group of admins held a vote in order to have me desysoped (and they lost it).
- Thirdly, if the de.wikisource community decides, by vote or by
consensus, that they want IPs to be allowed to change the quality status of pages, they can do this without destroying ProofreadPage. They just need to step out of the ProofreadPage quality system, and restore their previous system in place of it. I am willing to explain how to do this to any technically skilled person. Note that I already made the same proposal in bugzilla 8 months ago.
I apologize for the length of my answer. I wish to thank those who have had the patience to read this entire post.
Thomas
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
I know that I am over the "he said, she said" conversations of deWS. Accept that you have different perspective and recollections, accept that maybe that each of the others point of view may be how they see it from their recollection, and not consider it lying. Maybe, agree to differ and move one.
From the outside, you actually agree on more than you disagree, identify the issues that
you see need resolving, and see if you can. If you both parties think that it is worthy of resolving, then find a mediator. If it isn't going to resolve, move on.
I can understand that ThomasV has a software extension that he has built from a very definite principled point of view, then not want the tool used for something that is against his principles. I can and do support his right to limit a tool's use within his principles, and that sets aside whether I agree or disagree with his point of view.
To the point of validation of previously validated works. You can get a bot to go through and change the <pagequality> of a work if that is accepted by the community
Regards, Andrew
On 2 Jul 2010 at 0:08, Michael Jörgens wrote:
I don't know if there is an sense to reply to this mail, because is only a copy of the same boring discussion we had several times. And which can be broken down to the sarcastic sentence. "I the developer know what is good for the world, and everybody has to follow my will''. If he wants to overrule his own community, or there is a consensus there to have these hard coded rules, in a configurable system he can set the flags accordingly. If an other community has more confidence in their community and don't want the hard rules, set the flags to the according values and everybody (or all except one) will be happy.
And you can be shure that there is a broad consensus by the real active people to get the ip's editing allowed. And the second point he always forgets to mention, is that he make us a lot of work to transfer older projects to this extension. He is not willing to give the right to set pages which have been validated before to the validated state by transferring it to his extension. Even Admins are excluded from doing that.
Sorry for beeing a little bit sarcastic,but I think i've (we) had this discussion with ThomasV now 4 or 5 times. And I don't find a way to get a good solution, together with him.
Greetings
2010/7/1 ThomasV thomasV1@gmx.de
Here is my answer to the statements made recently.
- For those who are not familiar with the issue, I am the main
developer of ProofreadPage, a Mediawiki software extension that allows Wikisource users to proofread a page of text by comparing it to its scanned source. This extension also manages book metadata and citation information, and it imposes a very basic processing workflow, where a page must have been checked by two different users in order to reach its final state. [see here : http://en.wikisource.org/wiki/Help:Page_Status]
[snip]
Hi Thomas,
if someone gave you a patch which made the functionality desired by several members of the German Wikisource non-default optional, would you apply it? (It seems that John wants to develop something along these lines, if I interpret his post correctly.)
Best regards, Alexander
I recently had an interesting IRC discussion with two users of the German Wikisource (PDD and Paulis). It turned out that what they request is not a complete disabling of the extension's identity check, as I thought previously. They want IPs to be allowed to modify quality levels, but they also agree with the extension forbidding to the same user to set both q3 and q4, or to set q4 directly.
I think that I can accept such a solution, because it would not strongly damage the semantics of q3 and q4. It remains to be seen if this solution can be accepted by the rest of the de.ws community. They both seemed confident about that.
Thomas
Alexander Klauer a écrit :
Hi Thomas,
if someone gave you a patch which made the functionality desired by several members of the German Wikisource non-default optional, would you apply it? (It seems that John wants to develop something along these lines, if I interpret his post correctly.)
Best regards, Alexander
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
Cool. Thanks, ThomasV.
2010/7/3 ThomasV thomasV1@gmx.de
I recently had an interesting IRC discussion with two users of the German Wikisource (PDD and Paulis). It turned out that what they request is not a complete disabling of the extension's identity check, as I thought previously. They want IPs to be allowed to modify quality levels, but they also agree with the extension forbidding to the same user to set both q3 and q4, or to set q4 directly.
I think that I can accept such a solution, because it would not strongly damage the semantics of q3 and q4. It remains to be seen if this solution can be accepted by the rest of the de.ws community. They both seemed confident about that.
Thomas
Alexander Klauer a écrit :
Hi Thomas,
if someone gave you a patch which made the functionality desired by several members of the German Wikisource non-default optional, would you apply it? (It seems that John wants to develop something along these lines, if I interpret his post correctly.)
Best regards, Alexander
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
ok, I just commited a configuration option that will allow anons to modify pagequality levels.
In the future, I plan to automate semi-protection of pages when they reach q4 ; this task is currently being done by robots at de.ws. Note that this option might cause problems when semi-protection is enabled, because an anonymous user who sets a page to q4 will be locked out from editing again. We can restrict IPs to q3 in users in order to avoid that.
Thomas
ThomasV a écrit :
I recently had an interesting IRC discussion with two users of the German Wikisource (PDD and Paulis). It turned out that what they request is not a complete disabling of the extension's identity check, as I thought previously. They want IPs to be allowed to modify quality levels, but they also agree with the extension forbidding to the same user to set both q3 and q4, or to set q4 directly.
I think that I can accept such a solution, because it would not strongly damage the semantics of q3 and q4. It remains to be seen if this solution can be accepted by the rest of the de.ws community. They both seemed confident about that.
Thomas
Hi Andrew
I'm sorry for replying so late, thank you very much for your offer, I'm sure that I (we) will contact you, when we convert the next old projects. But at the moment were are pushing hard to reduce the unvalidated pages especially on projects which stay here for a long time without any progress - we call them Altlasten (inherited burdens).
ThomasV,
I'm quite happy, that we found an agreement for the IP's and proofread.
greetings joergens.mi
2010/7/9 ThomasV thomasV1@gmx.de
ok, I just commited a configuration option that will allow anons to modify pagequality levels.
In the future, I plan to automate semi-protection of pages when they reach q4 ; this task is currently being done by robots at de.ws. Note that this option might cause problems when semi-protection is enabled, because an anonymous user who sets a page to q4 will be locked out from editing again. We can restrict IPs to q3 in users in order to avoid that.
Thomas
ThomasV a écrit :
I recently had an interesting IRC discussion with two users of the German Wikisource (PDD and Paulis). It turned out that what they request is not a complete disabling of the extension's identity check, as I thought previously. They want IPs to be allowed to modify quality levels, but they also agree with the extension forbidding to the same user to set both q3 and q4, or to set q4 directly.
I think that I can accept such a solution, because it would not strongly damage the semantics of q3 and q4. It remains to be seen if this solution can be accepted by the rest of the de.ws community. They both seemed confident about that.
Thomas
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
On 07/01/2010 12:22 PM, ThomasV wrote:
I apologize for the length of my answer. I wish to thank those who have had the patience to read this entire post.
The problem is not a long post or two, but the fact that you seem to have locked yourself to this single issue. I'd like to discuss some far more visionary changes in how Wikisource works, but all you can talk about are these two stages of proofreading.
Let me start from another angle: Does anybody have experience from teaching beginners how to contribute to Wikisource? What are the hardest concepts to explain? I think we should compile and rank the current obstacles to the growth of Wikisource.
Just as one example, I would put the multiple namespaces (Index: and Page:) pretty high on that list, and I think that a redesign could do away with them. There was indeed a bug report filed for something similar, from the Polish community, that wanted to disconnect the naming of Index pages from the naming of PDF/Djvu files:
"<pagelist> should have file parameter", https://bugzilla.wikimedia.org/show_bug.cgi?id=21398
ThomasV replied with "WONTFIX", which is understandable since this is not a simple bug fix, but a more complicated change of architecture. The problem is that this architecture was never documented, so we don't know which the design decisions are. Or was it?
This is just one example of how Wikisource is really overly complicated, putting extra burden on newcomers, and where Wikisource would benefit from a redesign. But my suggestion is that we start to compile a catalog of such problems, rather than submitting bug reports. Where is a good place to start?
But my suggestion is that we start to compile a catalog of such problems, rather than submitting bug reports. Where is a good place to start?
Could it be this very mailing list, because AFAIK there is no active page for discussing about intersource matters. Another place could be Gdansk: probably several of us are willing to go to Wikimania, an I consider it a crucial occasion to meet, discuss and understand each other. Wikisources are many, very different and extremely complicated, but with great, huge potential. Best thing we can do is to see each other in the eyes and start creating a proper intersource community, sharing experiences, competences and ideas. I'll be there, hope you'll be too. Maybe we can arrange a meeting.
Aubrey
I can't agrre to the argumentation of Lars, that index and page name spaces are a bad solution. I think ThomasV has seen the problems of mixing articles and scan pages in a single work space. In de.ws we had this, before we started with ThomasV (PR2) extension. In the beginning I can't see any benefit from this method and argued against it. But meantime after working quite a long time with ThomaV System, I see that it is more comfortable to make a difference between the working place (index / page) and the presentation room (main) workspace.
And I think most of our community is thinking the same way. New projects are started with PR2, the number of projects startet with PR1 (the js-solution we had before) extension is nearly to zero. We are working on transfering older projects to PR2, even with the inherited problems mentioned above.
@ThomasV, my reply to your last post, 3 hours ago
"They want *IP*s to be *allowed to modify quality levels*, but they also agree with the extension *forbidding* to the *same use**r to set both q3 and q4*, or to *set q4 **directly*." ( bold settings are done by me)
*I agree completely* to this statement you've extracted from your discussion with paulis and pdd. I'm quite confident, that this can be called a consens in the de.community.
But there is * one wish **from** me*, is there a possibilty, to add a solution for transfering a validated old project to your PR2 extension directly - maybe be giving (an) admin the right to set q4 directly - but restricted to that purpose.
Greetings joergens.mi
2010/7/3 Andrea Zanni zanni.andrea84@gmail.com
But my suggestion is that we start to compile a catalog
of such problems, rather than submitting bug reports. Where is a good place to start?
Could it be this very mailing list, because AFAIK there is no active page for discussing about intersource matters. Another place could be Gdansk: probably several of us are willing to go to Wikimania, an I consider it a crucial occasion to meet, discuss and understand each other. Wikisources are many, very different and extremely complicated, but with great, huge potential. Best thing we can do is to see each other in the eyes and start creating a proper intersource community, sharing experiences, competences and ideas. I'll be there, hope you'll be too. Maybe we can arrange a meeting.
Aubrey
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
On 07/03/2010 03:41 PM, Michael Jörgens wrote:
And I think most of our community is thinking the same way. New projects are started with PR2, the number of projects startet with PR1 (the js-solution we had before) extension is nearly to zero. We are working on transfering older projects to PR2, even with the inherited problems mentioned above.
This is a little like saying that most members of the communist party think that a communist one-party state is just fine, so let's keep it. Such an absurd outcome, is the result of asking the wrong people. There's a very good book "The innovator's dilemma" (1997) that discusses this in detail.
The existing community is not the future growth of Wikisource. It's not even a majority of the future community, but it is rather small. Users who made >25 edits during May 2010 were 57 on fr.ws, 39 on de.ws, 15 on pl.ws, 11 on sv.ws, and 8 on ru.ws. So these five languages, which we consider active and running, have a total of 130 active users. This should need to be 1300 or 13,000. Last year, sv.ws had only 3-4 active users in a month, so we have more than doubled already during the spring of 2010.
That's why I want to ask what obstacles new users see, not what the current community is comfortable with.
It's fine that you can chose between PR1 and PR2. This is also why we should design "PR3", to give even more choice. And I want that to be radically easier to use.
Michael Jörgens a écrit :
But there is / one *wish *//from//* me*/, is there a possibilty, to add a solution for transfering a validated old project to your PR2 extension directly - maybe be giving (an) admin the right to set q4 directly - but restricted to that purpose.
I don't think that the import of old projects (a transient task) is a reason to permanently modify the balance of rights between sysops and normal users.
The most convenient way to import previously validated projects is to program a robot for the job.
Thomas
I do not agree with you on namespaces.
I think that the "Page" namespace is the best way to handle the separattion between the physical object (a book and its pages) and the logical object that we present to readers (the text, divided in sections or chapters)
The "Index" namespace is probably not as necessary as the "Page" namespace; if wikisource was using only djvu or pdf files, it would indeed be possible to go away with it, and to use the "File:" page for that purpose. However, there are still lots of projects that do not use multipage file formats ; we want to keep backward compatibility.
Thomas
Lars Aronsson a écrit :
I'd like to discuss some far more visionary changes in how Wikisource works, but all you can talk about are these two stages of proofreading.
Let me start from another angle: Does anybody have experience from teaching beginners how to contribute to Wikisource? What are the hardest concepts to explain? I think we should compile and rank the current obstacles to the growth of Wikisource.
Just as one example, I would put the multiple namespaces (Index: and Page:) pretty high on that list, and I think that a redesign could do away with them. There was indeed a bug report filed for something similar, from the Polish community, that wanted to disconnect the naming of Index pages from the naming of PDF/Djvu files:
"<pagelist> should have file parameter", https://bugzilla.wikimedia.org/show_bug.cgi?id=21398
ThomasV replied with "WONTFIX", which is understandable since this is not a simple bug fix, but a more complicated change of architecture. The problem is that this architecture was never documented, so we don't know which the design decisions are. Or was it?
This is just one example of how Wikisource is really overly complicated, putting extra burden on newcomers, and where Wikisource would benefit from a redesign. But my suggestion is that we start to compile a catalog of such problems, rather than submitting bug reports. Where is a good place to start?
2010/7/5 ThomasV thomasV1@gmx.de
The "Index" namespace is probably not as necessary as the "Page" namespace; if wikisource was using only djvu or pdf files, it would indeed be possible to go away with it, and to use the "File:" page for that purpose. However, there are still lots of projects that do not use multipage file formats ; we want to keep backward compatibility.
Thomas
On it.source we have a brief list of Index: pages using jpg images. We are converting them to djvu, the list isn't long but... the main list of "things to do" is very long... perhaps a converting tool exists? :-(
And, keeping the opportunity for a banal question: how can I download back by bot a list of jpgs? I tried pywikipedia scripts coupled with general download pythons scripts but I found that download scripts work on normal websites, but don't work on Commons (I only got a small piece of the jpg file, approx 1 kby).
Alex
On 07/05/2010 10:45 AM, ThomasV wrote:
I do not agree with you on namespaces.
I think that the "Page" namespace is the best way to handle the separattion between the physical object (a book and its pages) and the logical object that we present to readers (the text, divided in sections or chapters)
I agree that having two structures (physical pages and chapters) is a challenge (I even wrote a paper about this, eleven years ago), but the introduction of the Page: namespace is not without problems.
Moving the physical structure to its own namespace is based on the assumption that a separate presentation structure (the chapters of the book) exists and is the more important one. But for odd formats such as dictionaries or newspapers, this is far from obvious.
Should each dictionary entry become a chapter of its own? One dictionary might have 150,000 entries.
For newspapers, it's easy to agree that each major news article can be a chapter of its own. But maybe not each small advertisement? Should the whole ad section be one chapter? People might want to search these ads. They can be far more important to current readers than the news. So treating them as whitespace is not a solution.
In such cases, it might be best to just proofread the physical page and keep it as it is. Even for ordinary books, while they are being proofread, which can extend for months or years, only the physical structure exists. But then the Page: is what will be exposed to the public reader. So maybe it should be dressed up with the green {{header}} to look nicer?
Already today, we have the problem that searches using the site's own search box will show content in the Page: namespace, rather than the transcluded chapters in the main namespace (related to https://bugzilla.wikimedia.org/show_bug.cgi?id=18861 ) and there are no links from the found Page: to the chapters that transclude its text, unless you bother to use "what links here".
Wikistats (Erik Zachte) also reports user activity based on the main namespace. It's odd that on Wikisource, the "other" namespaces have far more editing activity than the main one.
For a dictionary, creating 150,000 tiny pages that each transclude 2 lines of text is not a good match for the current wiki technology. Having dozens of <section.../> tags in each page, will also look very clumsy. It would be comfortable if the section markers were much smaller, and treated like anchor points. Search should also return the closest preceding anchor point (even if that is on a preceding page), rather than the page URL.
The Bible, being one of the oldest texts on Wikisource, is a good test case. It consists of 2 testaments, 66 books, 1189 chapters and 31,103 verses. When printed on paper, it typically fits on 1200 physical pages. Today we typically create one wiki page per book or per chapter, e.g. http://en.wikisource.org/wiki/Bible_(King_James)/Matthew and this is what turns up in searches, since it was imported from existing e-texts, rather than being proofread in Wikisource. These 66 or 1189 wiki pages have headlines for each chapter and anchor points for each verse, but these are not presented in the search results. Imagine you could search "candle under bushel" and up comes "Matthew 5:15", even if you had a proofread but not yet transcluded version divided into 1200 wiki pages in the Page: namespace. Today search turns up things such as "Page:The Granite Monthly Volume 5.djvu/82", which simply isn't pretty.
In my eyes, this means: 1) many problems (e.g. search) are generic problems, not connected with ProofreadPage, and 2) the existing ProofreadPage (PR2) may work okay for traditional books with chapters, but it can also co-exist with an alternative ProofreadPage that works better for dictionaries and newspapers.
Next, consider digitizing old maps with Wikisource, and matching them (through coordinate transformation) with OpenStreetMap.
2010/7/5 Lars Aronsson lars@aronsson.se
I agree that having two structures (physical pages and chapters) is a challenge (I even wrote a paper about this, eleven years ago), but the introduction of the Page: namespace is not without problems.
Very interesting, this is another piece of talk I'd like to import into our it.source Village pump.
Just an idea: perhaps a switch show/hide the image on the right into Page: namespace could be a partial solution for "strange cases", and this could be coupled with an inverse hide/show a header section.
Lars Aronsson a écrit :
Let me start from another angle: Does anybody have experience from teaching beginners how to contribute to Wikisource? What are the hardest concepts to explain? I think we should compile and rank the current obstacles to the growth of Wikisource.
Maybe I can provide answers to that question... at fr.ws we now have lots of contributions to the "Page:" namespace, and I think that we have a good experience on how to teach beginners on that.
I guess the hardest concept to explain is transclusion ; this should not come as a surprise to you, since you pointed out the existence of a "Page:" namespace as an obstacle.
The solution is simple : just forget about it, do not explain it to beginners :-) . It is something they do not need to understand right from the beginning ; they will discover it later.
Instead of trying to explain transclusion to beginners, we redirect them to the "Page" and "Index" namespaces, right from the beginning. And it works : many new contributors make their first contributions in the "Page" namespace, without knowing anything about transclusion.
How do we do this ? Of course, we use the "help" pages, but also : *we use the "welcome" message *we have a "contribute" toolbox, visible from everywhere, with a "random book" link that leads to a random index page. *we have categories of Index pages sorted by progress, and these categories can be reached from the RC page.
Of course, this comes at a cost : New users who started to contribute in this way do not always handle hyphenated words correctly, and they sometimes write the page header in the main box. But this is something they learn quickly, and it is a minor problem compared to the benefits.
Another difficult thing is the upload of djvu files and creation of index pages ; this is a bit difficult for beginners. However, if index pages are already created by more experienced users, then beginners can start proofreading immediately, and this allows them to get a taste of Wikisource. So, create as many index pages as you can. One of our contributors spends most of his time creating new index pages, and I believe that we owe him a lot of contributors. I also create an index page everytime I find a text that does not have scans. In addition, we are planning to create 1416 new index pages very soon with a robot, following an agreement with BnF/Gallica.
So the conclusion is : create lots of index pages, and expose them to as many beginners as possible.
Thomas
2010/7/5 ThomasV thomasV1@gmx.de
Maybe I can provide answers to that question... at fr.ws we now have lots of contributions to the "Page:" namespace, and I think that we have a good experience on how to teach beginners on that.
I guess the hardest concept to explain is transclusion ; this should not come as a surprise to you, since you pointed out the existence of a "Page:" namespace as an obstacle.
The solution is simple : just forget about it, do not explain it to beginners :-) . It is something they do not need to understand right from the beginning ; they will discover it later.
Instead of trying to explain transclusion to beginners, we redirect them to the "Page" and "Index" namespaces, right from the beginning. And it works : many new contributors make their first contributions in the "Page" namespace, without knowing anything about transclusion.
How do we do this ? Of course, we use the "help" pages, but also : *we use the "welcome" message *we have a "contribute" toolbox, visible from everywhere, with a "random book" link that leads to a random index page. *we have categories of Index pages sorted by progress, and these categories can be reached from the RC page.
Of course, this comes at a cost : New users who started to contribute in this way do not always handle hyphenated words correctly, and they sometimes write the page header in the main box. But this is something they learn quickly, and it is a minor problem compared to the benefits.
Another difficult thing is the upload of djvu files and creation of index pages ; this is a bit difficult for beginners. However, if index pages are already created by more experienced users, then beginners can start proofreading immediately, and this allows them to get a taste of Wikisource. So, create as many index pages as you can. One of our contributors spends most of his time creating new index pages, and I believe that we owe him a lot of contributors. I also create an index page everytime I find a text that does not have scans. In addition, we are planning to create 1416 new index pages very soon with a robot, following an agreement with BnF/Gallica.
So the conclusion is : create lots of index pages, and expose them to as many beginners as possible.
Thomas
Thomas, just a couple of hours ago I posted into our "bar" (our village pump) a question, and your text seems the answer. :-)
http://it.wikisource.org/wiki/Wikisource:Bar#Brainstorming:_il_messaggio_di_...
I'll copy your post there, I hope you like this idea.
Alex
Michael Jörgens a écrit :
*There* is a bug, with zooming of the scans in PR2, the scrollbar vanishes, and the picture itself is growing ore reducing itself - uninterruptable-
Yes, that problem occurs with recent versions of Firefox. I have fixed it, but the new code is not active yet. As a temporary solution, you can disable the mouse wheel zoom on the wiki, and use only the new zoom method, where you draw a rectangle.
in Common.js, add :
self.proofreadpage_disable_wheelzoom=true;
Thomas
ThomasV, thank you for the information
joergens.mi
2010/7/1 ThomasV thomasV1@gmx.de
Michael Jörgens a écrit :
*There* is a bug, with zooming of the scans in PR2, the scrollbar vanishes, and the picture itself is growing ore reducing itself - uninterruptable-
Yes, that problem occurs with recent versions of Firefox. I have fixed it, but the new code is not active yet. As a temporary solution, you can disable the mouse wheel zoom on the wiki, and use only the new zoom method, where you draw a rectangle.
in Common.js, add :
self.proofreadpage_disable_wheelzoom=true;
Thomas
Wikisource-l mailing list Wikisource-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l
wikisource-l@lists.wikimedia.org