Hoi, Can someone please explain why this is ? Thanks, GerardM
2009/2/1 Marcus Buck wiki@marcusbuck.org
According to SiteMatrix we have 739 projects at the moment. There are three master partitions for the servers: s1 for enwiki only, s2 for 19 other projects and s3 for all the rest (that's 719 projects).
My homewiki is one of those 719 projects. And I feel a bit neglected. Replication is halted since 34 days. LuceneSearch 2.1 is active on enwiki since October and on dewiki and some other big wikis since December. Most other wikis have still no access to the new features. Even the "+incategory:" feature which is active on enwiki since April 2008 is not active on most wikis as of February 2009.
It seems, we are very low at the priority list.
Marcus Buck
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Everything takes time. The techs will handle it when they get around to it.
________________________________ From: Gerard Meijssen gerard.meijssen@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org; Wikimedia Foundation Mailing List foundation-l@lists.wikimedia.org Sent: Monday, February 2, 2009 3:26:02 AM Subject: Re: [Foundation-l] [Wikitech-l] second-class wikis
Hoi, Can someone please explain why this is ? Thanks, GerardM
2009/2/1 Marcus Buck wiki@marcusbuck.org
According to SiteMatrix we have 739 projects at the moment. There are three master partitions for the servers: s1 for enwiki only, s2 for 19 other projects and s3 for all the rest (that's 719 projects).
My homewiki is one of those 719 projects. And I feel a bit neglected. Replication is halted since 34 days. LuceneSearch 2.1 is active on enwiki since October and on dewiki and some other big wikis since December. Most other wikis have still no access to the new features. Even the "+incategory:" feature which is active on enwiki since April 2008 is not active on most wikis as of February 2009.
It seems, we are very low at the priority list.
Marcus Buck
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Geoffrey Plourde hett schreven:
Everything takes time. The techs will handle it when they get around to it.
That's a true answer, but at the same time as useless as it can be. If it's indeed only a matter of "getting around to it" (is it?), then the fact that they didn't came around to it since April 2008 would proove my "accusation" that the "little projects" are indeed regarded second-class.
Marcus Buck
On Mon, Feb 2, 2009 at 11:44 AM, Marcus Buck me@marcusbuck.org wrote:
That's a true answer, but at the same time as useless as it can be. If it's indeed only a matter of "getting around to it" (is it?), then the fact that they didn't came around to it since April 2008 would proove my "accusation" that the "little projects" are indeed regarded second-class.
The reason s3 replication is halted on the toolserver and not s1 or s2 is apparently because Wikimedia deleted the needed s3 logs but not the s1 or s2 logs. The reason they did this is probably because the master database server for s3 ran out of disk space more quickly than the masters for s1 and s2, requiring more old logs to be deleted. It's not because of discrimination against the little projects, it's mainly just dumb luck that s3 is what got hit (maybe the server had less free disk space for some reason, or more logs).
The reimport process could have started sooner. However, new servers were about to arrive, so River decided to postpone it until they did, for administrative convenience.
I don't think any of this is some plot against the small wikis. I remember a very long period of time when s1 (and only s1, the English Wikipedia) was continuously lagged hours, days, or longer, while s2 (and s3, if that existed by then) was up-to-date. This, again, was for technical reasons, not political ones.
This should really be on toolserver-l, though.
On Mon, Feb 2, 2009 at 5:26 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Can someone please explain why this is ? Thanks, GerardM
Also, some of the (to use the same language as the poster) "first class wikis" (top 10 on article count, on numbr of visits, wikipedia.org main page etc) are also on s3 and suffering the replag.
So it's more a case of bad luck than a case of disdain for smaller wikis.
Hoi, I had a word with Duesentrieb, he works for the German chapter, and he told me that the server issue is indeed a case of bad luck. He had some good news as well, Duesentrieb and some other Tool Server developers are looking into localisation for the tool server software. When the tool server tools are internationalised and localised, the tool server will get more users. With more users it becomes less acceptable that a service that has grown in importance is available for a third of our capacity. The localisation work will be done at Betawiki so that we keep our localisation and internationalisation effort focused.
There has not been a satisfactory answer to the question why certain services are not equally distributed over the services. When the localisation and internationalisation of the tool server starts to kick in, the priority of providing an equal support will be raised because increased use will make these issues more visible and consequently it will not be as acceptable as it currently seems to be. Thanks, GerardM
2009/2/2 Pedro Sanchez pdsanchez@gmail.com
On Mon, Feb 2, 2009 at 5:26 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Can someone please explain why this is ? Thanks, GerardM
Also, some of the (to use the same language as the poster) "first class wikis" (top 10 on article count, on numbr of visits, wikipedia.org main page etc) are also on s3 and suffering the replag.
So it's more a case of bad luck than a case of disdain for smaller wikis.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Mon, Feb 2, 2009 at 4:55 PM, Gerard Meijssen gerard.meijssen@gmail.comwrote:
There has not been a satisfactory answer to the question why certain services are not equally distributed over the services. When the localisation and internationalisation of the tool server starts to kick in, the priority of providing an equal support will be raised because increased use will make these issues more visible and consequently it will not be as acceptable as it currently seems to be. Thanks, GerardM
Because enwiki requires a lot more resources by itself than most other wikis combined? That's why it gets its own cluster. Nobody is saying that the s3 replication is acceptable. Pretty much everyone who has said anything to the subject has agreed that yes, there is a problem. The fact that s3 died and s1 and s2 remained up is, as you and others have mentioned, is bad luck. If it had been s1 that died, we'd see similar complaints about a lack of support for the biggest wiki. When it is said that fixes are in the works and to please be patient, it serves no purpose to continue bringing it up. The horse is dead, stop beating it senseless.
As to why the Lucene stuff hasn't been rolled out 100%, I cannot say (although Aryeh did bring up some good points I wasn't aware of). Perhaps there needs to be some more fine tuning before its more widely rolled out? As with most things: bugfixes and problem solving take precedence over new features (as well they should). Perhaps there've been issues with other things that have pulled time away from rolling out this new feature.
I don't know what this thread expects. From the subject alone, I'm thinking the only acceptable answer is "Yes, there's a massive conspiracy against smaller wikis. Now you've figured us out." What answer would you have developers give?
-Chad
OT: Shouldn't this be on toolserver-l and/or wikitech-l? It *hardly* involves the foundation.
Hoi, A conspiracy is wilful. I doubt that this is the case. If anything there is neglect. Other languages are just not given the same priority. What you hope for is that over time a language community will include developers that will take care for its language issues. In the mean time the Betawiki developers do what they can and I think they do a pretty good job.
As I said earlier, there are moves to start localising the tools of the Tool Server. This will make a lot of difference. We learned a lot from just starting the Commonist extension. As a localisation project it is a success, the unresolved question is how to reliably get new "builds" that include the latest localisation. This takes resources that we do not have.
What I hope for is that you, the developers, find this a reasonable assessment of the situation. Either way, the aim is to provide the best possible service and I hope you can agree that there is still much to do. Thanks, GerardM
2009/2/2 Chad innocentkiller@gmail.com
On Mon, Feb 2, 2009 at 4:55 PM, Gerard Meijssen gerard.meijssen@gmail.comwrote:
There has not been a satisfactory answer to the question why certain services are not equally distributed over the services. When the localisation and internationalisation of the tool server starts to kick
in,
the priority of providing an equal support will be raised because
increased
use will make these issues more visible and consequently it will not be
as
acceptable as it currently seems to be. Thanks, GerardM
Because enwiki requires a lot more resources by itself than most other wikis combined? That's why it gets its own cluster. Nobody is saying that the s3 replication is acceptable. Pretty much everyone who has said anything to the subject has agreed that yes, there is a problem. The fact that s3 died and s1 and s2 remained up is, as you and others have mentioned, is bad luck. If it had been s1 that died, we'd see similar complaints about a lack of support for the biggest wiki. When it is said that fixes are in the works and to please be patient, it serves no purpose to continue bringing it up. The horse is dead, stop beating it senseless.
As to why the Lucene stuff hasn't been rolled out 100%, I cannot say (although Aryeh did bring up some good points I wasn't aware of). Perhaps there needs to be some more fine tuning before its more widely rolled out? As with most things: bugfixes and problem solving take precedence over new features (as well they should). Perhaps there've been issues with other things that have pulled time away from rolling out this new feature.
I don't know what this thread expects. From the subject alone, I'm thinking the only acceptable answer is "Yes, there's a massive conspiracy against smaller wikis. Now you've figured us out." What answer would you have developers give?
-Chad
OT: Shouldn't this be on toolserver-l and/or wikitech-l? It *hardly* involves the foundation. _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Gerard Meijssen wrote:
Hoi, A conspiracy is wilful. I doubt that this is the case. If anything there is neglect. Other languages are just not given the same priority.
There's no language-dependence in our priorities here, except for Robert's initial decision, back in October, to pilot the new software on the largest wikis. The smaller wikis haven't been neglected since then, rather, the search engine has been neglected.
The English Wikipedia has often been left out of toolserver replication, and it could have easily been the case this time around.
What you hope for is that over time a language community will include developers that will take care for its language issues. In the mean time the Betawiki developers do what they can and I think they do a pretty good job.
The Betawiki developers, as I believe you yourself have pointed out, are part of the community.
-- Tim Starling
Hoi, There are language issues that are not addressed. It is known for instance that the Safari browser supports Lingala better then Firefox and Opera. This is because Safari does NOT use a monospaced font in the edit screen. An obvious but not so elegant solution would be to have these other two browsers also not have monospaced fonts used. The problem is that an elegant solution is outside of MediaWIki... There are more issues like this and they need to be given a WMF priority to fix this. There are several other issues that can be addressed when language itself is given priority.
When you state that language-dependence in the priorities, you are exactly right. The trouble is that the "other" languages do not function properly and this is not really considered. For English things work per default. So if all other languages are considered as equal, you neglect the fact that this is not true for other languages. If the search engine is broken in the first place then it is not acceptable to use it if you state that all languages are treated equally. Leaving them "for now" is a temporary solution. There is however nothing as permanent as a temporary solution.
As to the Tool Server replication, I have written that this is just bad luck. Indeed it could be the one for English. In a way, the Tool Server is quicky, it is good that it is not as bad as the backup situation.
I will be indeed the last to say that the Betawiki developers are not part of the community of MediaWiki developers. The point that I tried to make here is that when the Lingala community produces its *own *developer, they will have a better grasp of the issues with the Lingala language. There are no Betawiki developers who know about the needs of African languages. I know I can find such developers through people like Don Osborne and Martin Benjamin. They are programmers that are for hire. If we want a more complete solution, language needs to be given a priority and the many issues need to be identified first and addressed later. It is not only about Lingala. Thanks, GerardM
2009/2/3 Tim Starling tstarling@wikimedia.org
Gerard Meijssen wrote:
Hoi, A conspiracy is wilful. I doubt that this is the case. If anything there
is
neglect. Other languages are just not given the same priority.
There's no language-dependence in our priorities here, except for Robert's initial decision, back in October, to pilot the new software on the largest wikis. The smaller wikis haven't been neglected since then, rather, the search engine has been neglected.
The English Wikipedia has often been left out of toolserver replication, and it could have easily been the case this time around.
What you hope for is that over time a language community will include developers that
will
take care for its language issues. In the mean time the Betawiki
developers
do what they can and I think they do a pretty good job.
The Betawiki developers, as I believe you yourself have pointed out, are part of the community.
-- Tim Starling
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Gerard Meijssen wrote:
I will be indeed the last to say that the Betawiki developers are not part of the community of MediaWiki developers. The point that I tried to make here is that when the Lingala community produces its *own *developer, they will have a better grasp of the issues with the Lingala language. There are no Betawiki developers who know about the needs of African languages. I know I can find such developers through people like Don Osborne and Martin Benjamin. They are programmers that are for hire. If we want a more complete solution, language needs to be given a priority and the many issues need to be identified first and addressed later. It is not only about Lingala.
There's no doubt it's useful to have programmers who speak the language. They often come with the motivation to work on language-related problems, an understanding of the wiki community, and familiarity with the linguistics and data sources. Our Chinese variant feature, for instance, has benefited greatly from work by Chinese-speaking developers.
But results can certainly be achieved if you have a bilingual community member with no knowledge of programming, and a programmer willing to work with them. We've even done language-related features with no help from speakers whatsoever, just using online linguistics resources.
So I don't think the lack of a Lingala-speaking developer should be considered a roadblock for the development of Lingala-related features.
-- Tim Starling
wikimedia-l@lists.wikimedia.org