Given the hurricane of bullshit that erupted over the rollback right in en.wikipedia after JeLuf made the switch, can someone with the Foundation please direct the developers to switch it back off until some semblance of an agreement can be attained? In the mean time, its a wild and crazy shooting match between admins that is sucking attention away from anything actually consequential.
Nathan
On 11/01/2008, Nathan nawrich@gmail.com wrote:
Given the hurricane of bullshit that erupted over the rollback right in en.wikipedia after JeLuf made the switch, can someone with the Foundation please direct the developers to switch it back off until some semblance of an agreement can be attained? In the mean time, its a wild and crazy shooting match between admins that is sucking attention away from anything actually consequential.
Nathan
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Where is the consensus for it to be switched off?
On Jan 11, 2008 10:40 AM, Majorly axel9891@googlemail.com wrote:
Where is the consensus for it to be switched off?
More importantly, where was the consensus to turn it on in the first place. From what I hear, no such consensus was ever obtained (i could be wrong on that).
--Andrew Whitworth
On Jan 11, 2008 4:44 PM, Andrew Whitworth wknight8111@gmail.com wrote:
On Jan 11, 2008 10:40 AM, Majorly axel9891@googlemail.com wrote:
Where is the consensus for it to be switched off?
More importantly, where was the consensus to turn it on in the first place. From what I hear, no such consensus was ever obtained (i could be wrong on that).
More importantly, wtf are you talking about? A link or a short explanation would be welcome.
A summary, for those who are completely lost:
Recently developers added the ability for admins on the English Wikipedia to grant rollback rights to non-admin accounts.
This followed a large discussion and vote on enwiki in which ~2/3 of participants favored this feature
http://en.wikipedia.org/wiki/Wikipedia:Non-administrator_rollback/Poll Unfortunately, 2/3 is a ambiguous standard for consensus on enwiki and previous developer requests have been denied with higher standards of support.
So now there is a large debate on enwiki about whether or not there was consensus. In the meantime, other people are moving full steam ahead with Requests for Rollback (http://en.wikipedia.org/wiki/Wikipedia:RFR) with about 400 people having been given rollback rights so far through a variety of informal and semi-formal processes.
There is also an arbitration request ( http://en.wikipedia.org/wiki/Wikipedia:RFAr#Rollback_consensus) whose arguments provide a variety of background. Presently the enwiki Arbs seem inclined to decline the arbitration request on the grounds that setting policy is really a community issue and not a place for Arbcom dictates.
Personally, I think this is far more of a tempest in a tea cup than a real major problem. It appears to have spilled over here because some people want the Foundation to order the developers to switch this new feature off. While I can't speak for the Foundation, I would think those people would be better served by talking to developers directly, or trying to come to some resolution on enwiki itself.
-Robert Rohde
On Jan 11, 2008 7:50 AM, Guillaume Paumier guillom.pom@gmail.com wrote:
On Jan 11, 2008 4:44 PM, Andrew Whitworth wknight8111@gmail.com wrote:
On Jan 11, 2008 10:40 AM, Majorly axel9891@googlemail.com wrote:
Where is the consensus for it to be switched off?
More importantly, where was the consensus to turn it on in the first place. From what I hear, no such consensus was ever obtained (i could be wrong on that).
More importantly, wtf are you talking about? A link or a short explanation would be welcome.
-- Guillaume Paumier [[m:User:guillom]] "Go confidently in the direction of your dreams. Live the life you have imagined." Henry David Thoreau
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Robert Rohde wrote:
A summary, for those who are completely lost:
Recently developers added the ability for admins on the English Wikipedia to grant rollback rights to non-admin accounts.
This followed a large discussion and vote on enwiki in which ~2/3 of participants favored this feature
And there was me picturing a giant dinosaur rampaging through Wikipedia undoing random edits and terrorising admins. :-P
If I recall correctly you could get some Javascript included in your setup to perform the same function. This just levels the playing field a bit.
Brian McNeil
If I recall correctly you could get some Javascript included in your setup to perform the same function. This just levels the playing field a bit.
But if that were true, then +rollbacker wouldn't be a big deal. And if that were true, then maybe +sysop wouldn't be a big deal either. And we couldn't have that, now could we?! Mike.lifeguard (@ en.wb and not at en.wp as much I can help it)
On Friday 11 January 2008 20:32, mike.lifeguard wrote:
If I recall correctly you could get some Javascript included in your setup to perform the same function. This just levels the playing field a bit.
But if that were true, then +rollbacker wouldn't be a big deal. And if that were true, then maybe +sysop wouldn't be a big deal either. And we couldn't have that, now could we?!
You just gave me an idea of a sysop day, when every user (perhaps older than a few days) could be a sysop. Could decrease animosity between users and sysops (though also have some negative consequences ;) .
Hoi, This is true. At OmegaWiki we do not have a problem with a difference between admin and users because there is no difference. People are trusted from the start. One implication is that because it is trust that is given, it is losing the trust that does allow taking the admin bits away. So far there has been no problem at all with this. Indeed the biggest benefit is that we do have much less of a problem with vandals. Thanks, GerardM
On Jan 12, 2008 8:36 AM, Nikola Smolenski smolensk@eunet.yu wrote:
On Friday 11 January 2008 20:32, mike.lifeguard wrote:
If I recall correctly you could get some Javascript included in your
setup
to perform the same function. This just levels the playing field a bit.
But if that were true, then +rollbacker wouldn't be a big deal. And if
that
were true, then maybe +sysop wouldn't be a big deal either. And we
couldn't
have that, now could we?!
You just gave me an idea of a sysop day, when every user (perhaps older than a few days) could be a sysop. Could decrease animosity between users and sysops (though also have some negative consequences ;) .
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Gerard Meijssen wrote:
Hoi, This is true. At OmegaWiki we do not have a problem with a difference between admin and users because there is no difference. People are trusted from the start. One implication is that because it is trust that is given, it is losing the trust that does allow taking the admin bits away. So far there has been no problem at all with this. Indeed the biggest benefit is that we do have much less of a problem with vandals.
Perhaps the difference may be that OmegaWiki has an active policy of assuming good faith.
Ec
On Jan 13, 2008 12:19 AM, Ray Saintonge saintonge@telus.net wrote:
Gerard Meijssen wrote:
Hoi, This is true. At OmegaWiki we do not have a problem with a difference between admin and users because there is no difference. People are trusted from the start. One implication is that because it is trust that is given, it is losing the trust that does allow taking the admin bits away. So far there has been no problem at all with this. Indeed the biggest benefit is that we do have much less of a problem with vandals.
Perhaps the difference may be that OmegaWiki has an active policy of assuming good faith.
No. It means they assume people will do bad until they approve them, after that they are all equally trusted.
At one point their mediawiki changes had no revision control which made that fairly necessary. I don't know if thats still the case.
On Jan 11, 2008 11:54 AM, Robert Rohde rarohde@gmail.com wrote:
A summary, for those who are completely lost:
Recently developers added the ability for admins on the English Wikipedia to grant rollback rights to non-admin accounts.
This followed a large discussion and vote on enwiki in which ~2/3 of participants favored this feature
[snip]
It's also the case that only one option was offered in that particular poll "admins can grant/revoke rollback from others". A lot of the critics of the current behavior are pointing out issues with wheel warring (which is already happening) and additional bureaucratic overhead. Many of those people would prefer an rollback be granted automatically, like page moves.
Considering that rollback is just a faster version of edit, just as move is a faster (and less problem causing) version of edit+ copy and paste, that makes sense to me. I was sold when I saw a user since 2005 in good standing rejected because he used the wrong template to apply for rollback, and the wheel warring. :)
I was greeted yesterday by a friendly message saying I'd been granted rollback. I didn't want it, I never asked for it. I never applied at WP:RFRASIJOAAJCSA for it. I asked for it to be removed, and it was. However, two issues are paramount in my mind:
A) When did rollback suddenly become the tool de jour? Why is it suddenly a must-have for all editors?
B) Why are some people so intent on giving it to out? As if the wiki would crumble without it?
Chad H.
On Jan 11, 2008 3:09 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Jan 11, 2008 11:54 AM, Robert Rohde rarohde@gmail.com wrote:
A summary, for those who are completely lost:
Recently developers added the ability for admins on the English Wikipedia to grant rollback rights to non-admin accounts.
This followed a large discussion and vote on enwiki in which ~2/3 of participants favored this feature
[snip]
It's also the case that only one option was offered in that particular poll "admins can grant/revoke rollback from others". A lot of the critics of the current behavior are pointing out issues with wheel warring (which is already happening) and additional bureaucratic overhead. Many of those people would prefer an rollback be granted automatically, like page moves.
Considering that rollback is just a faster version of edit, just as move is a faster (and less problem causing) version of edit+ copy and paste, that makes sense to me. I was sold when I saw a user since 2005 in good standing rejected because he used the wrong template to apply for rollback, and the wheel warring. :)
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On Jan 11, 2008 10:11 PM, Chad innocentkiller@gmail.com wrote:
I was greeted yesterday by a friendly message saying I'd been granted rollback. I didn't want it, I never asked for it. I never applied at WP:RFRASIJOAAJCSA for it. I asked for it to be removed, and it was. However, two issues are paramount in my mind:
A) When did rollback suddenly become the tool de jour? Why is it suddenly a must-have for all editors?
B) Why are some people so intent on giving it to out? As if the wiki would crumble without it?
Chad H.
On Jan 11, 2008 3:09 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Jan 11, 2008 11:54 AM, Robert Rohde rarohde@gmail.com wrote:
A summary, for those who are completely lost:
Recently developers added the ability for admins on the English Wikipedia to grant rollback rights to non-admin accounts.
This followed a large discussion and vote on enwiki in which ~2/3 of participants favored this feature
[snip]
It's also the case that only one option was offered in that particular poll "admins can grant/revoke rollback from others". A lot of the critics of the current behavior are pointing out issues with wheel warring (which is already happening) and additional bureaucratic overhead. Many of those people would prefer an rollback be granted automatically, like page moves.
Considering that rollback is just a faster version of edit, just as move is a faster (and less problem causing) version of edit+ copy and paste, that makes sense to me. I was sold when I saw a user since 2005 in good standing rejected because he used the wrong template to apply for rollback, and the wheel warring. :)
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
....
C) Why do people ignore the call to take this discussion to a mailing list where it belongs
On Jan 11, 2008 4:16 PM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
C) Why do people ignore the call to take this discussion to a mailing list where it belongs
Because they can't edit war over a mailing list, removing people's points and arguments that they disagree with as they are doing on the Wiki. :(
On 11/01/2008, Chad innocentkiller@gmail.com wrote:
I was greeted yesterday by a friendly message saying I'd been granted rollback. I didn't want it, I never asked for it. I never applied at WP:RFRASIJOAAJCSA for it. I asked for it to be removed, and it was. However, two issues are paramount in my mind:
A) When did rollback suddenly become the tool de jour? Why is it suddenly a must-have for all editors?
B) Why are some people so intent on giving it to out? As if the wiki would crumble without it?
Chad H.
On Jan 11, 2008 3:09 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Jan 11, 2008 11:54 AM, Robert Rohde rarohde@gmail.com wrote:
A summary, for those who are completely lost:
Recently developers added the ability for admins on the English
Wikipedia to
grant rollback rights to non-admin accounts.
This followed a large discussion and vote on enwiki in which ~2/3 of participants favored this feature
[snip]
It's also the case that only one option was offered in that particular poll "admins can grant/revoke rollback from others". A lot of the critics of the current behavior are pointing out issues with wheel warring (which is already happening) and additional bureaucratic overhead. Many of those people would prefer an rollback be granted automatically, like page moves.
Considering that rollback is just a faster version of edit, just as move is a faster (and less problem causing) version of edit+ copy and paste, that makes sense to me. I was sold when I saw a user since 2005 in good standing rejected because he used the wrong template to apply for rollback, and the wheel warring. :)
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
I dislike the fact users are giving it without even bothering to ask the user in question if they want it. That is pretty rude.
On 11/01/2008, Andrew Whitworth wknight8111@gmail.com wrote:
On Jan 11, 2008 10:40 AM, Majorly axel9891@googlemail.com wrote:
Where is the consensus for it to be switched off?
More importantly, where was the consensus to turn it on in the first place. From what I hear, no such consensus was ever obtained (i could be wrong on that).
--Andrew Whitworth
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
There was no consensus for undo, cascading protection, semi-protection etc..
Funny you should say that, since there was no consensus to switch it ON and that smooth move has turned into the disaster we have now. You've already argued a hundred times in other places that despite the lack of consensus to do it, undoing it requires a new consensus. I'm not claiming consensus in either direction, I'm claiming common sense. Since its an epic disaster, it should be put on hold until the issues around it can be resolved.
On 11/01/2008, Nathan nawrich@gmail.com wrote:
Funny you should say that, since there was no consensus to switch it ON and that smooth move has turned into the disaster we have now. You've already argued a hundred times in other places that despite the lack of consensus to do it, undoing it requires a new consensus. I'm not claiming consensus in either direction, I'm claiming common sense. Since its an epic disaster, it should be put on hold until the issues around it can be resolved.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
No consensus, in your opinion. To some, there was consensus. What number is your consensus then?
Sure, we can put it on hold - indeed the request page is locked. However, we don't need it switching off. At least, not yet.
I don't understand, the developers regularly enable new features with seeking (uneeded) consensus. For example, when they enabled cascading protection we gradually worked out the rules and methodology for it. We're doing the same thing with rollback with just a whole lot more fanfare and idiots involved.
--John Reaves
On Jan 11, 2008 7:45 AM, Nathan nawrich@gmail.com wrote:
Funny you should say that, since there was no consensus to switch it ON and that smooth move has turned into the disaster we have now. You've already argued a hundred times in other places that despite the lack of consensus to do it, undoing it requires a new consensus. I'm not claiming consensus in either direction, I'm claiming common sense. Since its an epic disaster, it should be put on hold until the issues around it can be resolved.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 11/01/2008, John Reaves johnreaveswp@gmail.com wrote:
I don't understand, the developers regularly enable new features with seeking (uneeded) consensus. For example, when they enabled cascading protection we gradually worked out the rules and methodology for it. We're doing the same thing with rollback with just a whole lot more fanfare and idiots involved.
--John Reaves
On Jan 11, 2008 7:45 AM, Nathan nawrich@gmail.com wrote:
Funny you should say that, since there was no consensus to switch it ON and that smooth move has turned into the disaster we have now. You've already argued a hundred times in other places that despite the lack of consensus to do it, undoing it requires a new consensus. I'm not claiming consensus in either direction, I'm claiming common sense. Since its an epic disaster, it should be put on hold until the issues around it can be resolved.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Yep. If this had been added just like undo/cascading protection, there'd have been a lot less complaining and moaning. We'd have just got on with it like sensible people.
Except it wasn't - and the result is widespread craziness, and only the developers (or the Foundation for which they work) can switch it off. Thats why its on this list. It was switched on based on an incorrect reading of the will of the community, and it should be switched off until a better sense can be obtained.
On Jan 11, 2008 10:54 AM, Majorly axel9891@googlemail.com wrote:
On 11/01/2008, John Reaves johnreaveswp@gmail.com wrote:
I don't understand, the developers regularly enable new features with seeking (uneeded) consensus. For example, when they enabled cascading protection we gradually worked out the rules and methodology for it. We're doing the same thing with rollback with just a whole lot more fanfare and idiots involved.
--John Reaves
On Jan 11, 2008 7:45 AM, Nathan nawrich@gmail.com wrote:
Funny you should say that, since there was no consensus to switch it ON and that smooth move has turned into the disaster we have now. You've already argued a hundred times in other places that despite the lack of consensus to do it, undoing it requires a new consensus. I'm not claiming consensus in either direction, I'm claiming common sense. Since its an epic disaster, it should be put on hold until the issues around it can be resolved.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Yep. If this had been added just like undo/cascading protection, there'd have been a lot less complaining and moaning. We'd have just got on with it like sensible people.
-- Alex (Majorly)
http://meta.wikimedia.org/wiki/User:Majorly _______________________________________________
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
I'm still trying to figure out why everyone cares. It's just rollback for Christ's sake.
Chad
On Jan 11, 2008 10:58 AM, Nathan nawrich@gmail.com wrote:
Except it wasn't - and the result is widespread craziness, and only the developers (or the Foundation for which they work) can switch it off. Thats why its on this list. It was switched on based on an incorrect reading of the will of the community, and it should be switched off until a better sense can be obtained.
On Jan 11, 2008 10:54 AM, Majorly axel9891@googlemail.com wrote:
On 11/01/2008, John Reaves johnreaveswp@gmail.com wrote:
I don't understand, the developers regularly enable new features with seeking (uneeded) consensus. For example, when they enabled cascading protection we gradually worked out the rules and methodology for it. We're doing the same thing with rollback with just a whole lot more fanfare and idiots involved.
--John Reaves
On Jan 11, 2008 7:45 AM, Nathan nawrich@gmail.com wrote:
Funny you should say that, since there was no consensus to switch it ON and that smooth move has turned into the disaster we have now. You've already argued a hundred times in other places that despite the lack of consensus to do it, undoing it requires a new consensus. I'm not claiming consensus in either direction, I'm claiming common sense. Since its an epic disaster, it should be put on hold until the issues around it can be resolved.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Yep. If this had been added just like undo/cascading protection, there'd have been a lot less complaining and moaning. We'd have just got on with it like sensible people.
-- Alex (Majorly)
http://meta.wikimedia.org/wiki/User:Majorly _______________________________________________
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 11/01/2008, Chad innocentkiller@gmail.com wrote:
I'm still trying to figure out why everyone cares. It's just rollback for Christ's sake.
Chad
Me too. It's drama for the sake of nothing.
On 11/01/2008, Nathan nawrich@gmail.com wrote:
Except it wasn't - and the result is widespread craziness, and only the developers (or the Foundation for which they work) can switch it off. Thats why its on this list. It was switched on based on an incorrect reading of the will of the community, and it should be switched off until a better sense can be obtained.
On Jan 11, 2008 10:54 AM, Majorly axel9891@googlemail.com wrote:
On 11/01/2008, John Reaves johnreaveswp@gmail.com wrote:
I don't understand, the developers regularly enable new features with seeking (uneeded) consensus. For example, when they enabled cascading protection we gradually worked out the rules and methodology for it. We're doing the same thing with rollback with just a whole lot more fanfare
and
idiots involved.
--John Reaves
On Jan 11, 2008 7:45 AM, Nathan nawrich@gmail.com wrote:
Funny you should say that, since there was no consensus to switch it ON and that smooth move has turned into the disaster we have now. You've already argued a hundred times in other places that despite
the
lack of consensus to do it, undoing it requires a new consensus. I'm not claiming consensus in either direction, I'm claiming common
sense.
Since its an epic disaster, it should be put on hold until the
issues
around it can be resolved.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Yep. If this had been added just like undo/cascading protection, there'd have been a lot less complaining and moaning. We'd have just got on with
it
like sensible people.
-- Alex (Majorly)
http://meta.wikimedia.org/wiki/User:Majorly _______________________________________________
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
The only people causing the craziness are the people loudly complaining on the talk pages. Everyone else is just getting on with it.
Nathan wrote:
Except it wasn't - and the result is widespread craziness, and only the developers (or the Foundation for which they work) can switch it off. Thats why its on this list.
Correct me if I'm wrong, but I believe the developer who made the switch is not an employee of the Wikimedia Foundation. Take it to wikitech-l or wikien-l, please.
--Michael Snow
On Jan 11, 2008 5:14 PM, Michael Snow wikipedia@att.net wrote:
Nathan wrote:
Except it wasn't - and the result is widespread craziness, and only the developers (or the Foundation for which they work) can switch it off. Thats why its on this list.
Correct me if I'm wrong, but I believe the developer who made the switch is not an employee of the Wikimedia Foundation. Take it to wikitech-l or wikien-l, please.
--Michael Snow
I completely agree. A) As far as I know, there is no foundation policy to whom projects should grant things like rollback B) It was not a WMF employer who made the decision
==> The foundation and subsequently foundation-l has nothing to do with this. Move it, please.
Michael
Aye aye.
Just to clarify Robert's remarks: Arbitration doesn't have a natural role in this necessarily, but the step was suggested by Jimbo.
~Nathan
Hi!
Correct me if I'm wrong, but I believe the developer who made the switch is not an employee of the Wikimedia Foundation. Take it to wikitech- l or wikien-l, please.
Well, there is quite a bit of foundation issue here, and I'd like to explaim some general projects bits (that are neither technology, nor single-project related):
See, Jens is not employee, though has been the developer with most community-facing attitude. He has been implementing, at his own will, most of community requests. He is a volunteer, and has been dedicated to our ideals more and longer than most of us. When members of communities decide to attack with "This developer has exhibited extremely poor judgment and a gross disregard for the WIkipedia community" and nobody takes that back or apologizes, it is no fun to continue doing all these small things.
Foundation doesn't really facilitate this process at the moment - it is all left to individual care - both filtering, evaluating if change X would successfully follow all few hundreds policy pages, and implementation, what often requires extensive code review and familiarity of our operating environment. Do note, that community representatives come not only with these changes - various 'oh noes, remove this from site' requests are quite common, and every of them are questionable.
If people will be going to raise such huge flames and attack implementors for actually doing the job, we will really ask foundation to facilitate not only all the evaluation of every request that comes in from communities, but to provide with implementor resources too.
We have far more fun things (our jobs, lives, even wikipedia technology development) to do than go into endless debates with people who favor endless debates, sorry.
Domas Mituzas wrote:
Hi!
Correct me if I'm wrong, but I believe the developer who made the switch is not an employee of the Wikimedia Foundation. Take it to wikitech- l or wikien-l, please.
Well, there is quite a bit of foundation issue here, and I'd like to explaim some general projects bits (that are neither technology, nor single-project related):
See, Jens is not employee, though has been the developer with most community-facing attitude. He has been implementing, at his own will, most of community requests. He is a volunteer, and has been dedicated to our ideals more and longer than most of us. When members of communities decide to attack with "This developer has exhibited extremely poor judgment and a gross disregard for the WIkipedia community" and nobody takes that back or apologizes, it is no fun to continue doing all these small things.
200% agree.
Foundation doesn't really facilitate this process at the moment - it is all left to individual care - both filtering, evaluating if change X would successfully follow all few hundreds policy pages, and implementation, what often requires extensive code review and familiarity of our operating environment. Do note, that community representatives come not only with these changes - various 'oh noes, remove this from site' requests are quite common, and every of them are questionable.
If people will be going to raise such huge flames and attack implementors for actually doing the job, we will really ask foundation to facilitate not only all the evaluation of every request that comes in from communities, but to provide with implementor resources too.
And we would do well to refuse doing such thing. Foundation would become a huge bottleneck and community will then begin complaining that we are hindering the development of the projects.
We have far more fun things (our jobs, lives, even wikipedia technology development) to do than go into endless debates with people who favor endless debates, sorry.
Could not agree more.
Ant
Hello!
And we would do well to refuse doing such thing. Foundation would become a huge bottleneck and community will then begin complaining that we are hindering the development of the projects.
Well understood and appreciated.
Yesterday I tried to do one tiny tiny change (es.wikipedia wanted to switch their timezone). Of course, after last flames it was fun to make a circus out of it (forced few people - sysops and bureaucrats to 'sign in blood'), but here again, accurately interpreting votes and resolutions in other languages, where there were multiple votes on same page, as well as Great Walls of Text, was nearly impossible.
Lots of things can be rolled forward and backwards, so usually no harm is done - except that it takes time and can cause some frustrations, if caught in the middle of heated debate.
So, we usually have just to trust that people who come and ask for things can really represent community, and are not going to undermine something in evil ways. Usually we like to trust, and love to trust. But sometimes a single campaign against can shatter it all.
So, we usually have just to trust that people who come and ask for things can really represent community, and are not going to undermine something in evil ways. Usually we like to trust, and love to trust. But sometimes a single campaign against can shatter it all.
This might be a good place for local ArbComs to step in. They can determine consensus and make the request to developers. Developers trying to determine consensus, especially on projects in languages they don't speak, is pretty much impossible - it comes down to a (hopefully lucky) guess.
--- Thomas Dalton thomas.dalton@gmail.com wrote:
So, we usually have just to trust that people who
come and ask for
things can really represent community, and are not
going to undermine
something in evil ways. Usually we like to trust, and love to trust. But
sometimes a single
campaign against can shatter it all.
This might be a good place for local ArbComs to step in. They can determine consensus and make the request to developers. Developers trying to determine consensus, especially on projects in languages they don't speak, is pretty much impossible - it comes down to a (hopefully lucky) guess.
How should the devs know which communities have an Arbcom that needs to approve the bug? I think any system put in here needs to, by default, not interfere with the devs doing their work. Giving communities more opportunities to raise a flag before implementaion is good. But requiring the devs check with X before every implementation, or any process external to Bugzilla, is bad.
Birgitte SB
____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Which is why I suggested an in-between person to help facilitate the developer <-> communities relationship.
Chad
On Jan 12, 2008 3:39 PM, Birgitte SB birgitte_sb@yahoo.com wrote:
--- Thomas Dalton thomas.dalton@gmail.com wrote:
So, we usually have just to trust that people who
come and ask for
things can really represent community, and are not
going to undermine
something in evil ways. Usually we like to trust, and love to trust. But
sometimes a single
campaign against can shatter it all.
This might be a good place for local ArbComs to step in. They can determine consensus and make the request to developers. Developers trying to determine consensus, especially on projects in languages they don't speak, is pretty much impossible - it comes down to a (hopefully lucky) guess.
How should the devs know which communities have an Arbcom that needs to approve the bug? I think any system put in here needs to, by default, not interfere with the devs doing their work. Giving communities more opportunities to raise a flag before implementaion is good. But requiring the devs check with X before every implementation, or any process external to Bugzilla, is bad.
Birgitte SB
____________________________________________________________________________________Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
How should the devs know which communities have an Arbcom that needs to approve the bug? I think any system put in here needs to, by default, not interfere with the devs doing their work. Giving communities more opportunities to raise a flag before implementaion is good. But requiring the devs check with X before every implementation, or any process external to Bugzilla, is bad.
The devs only make these kind of changes if someone asks them to, so if the rule is made that only ArbComs (or crats/admins if there is no ArbCom) can make such requests then the devs don't have to check with anyone, they just have to verify that the person asking really is a member of the project's ArbCom, which isn't that difficult. It's certainly easier than trying to work out if there's a consensus for the change.
On Jan 12, 2008 4:45 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
How should the devs know which communities have an Arbcom that needs to approve the bug? I think any system put in here needs to, by default, not interfere with the devs doing their work. Giving communities more opportunities to raise a flag before implementaion is good. But requiring the devs check with X before every implementation, or any process external to Bugzilla, is bad.
The devs only make these kind of changes if someone asks them to, so if the rule is made that only ArbComs (or crats/admins if there is no ArbCom) can make such requests then the devs don't have to check with anyone, they just have to verify that the person asking really is a member of the project's ArbCom, which isn't that difficult. It's certainly easier than trying to work out if there's a consensus for the change.
So few projects have arbcoms that it's unreasonable to include specific mention of them into any foundation-wide policy. The current method of asking for a bug is decent, requiring a link to be posted to a page where consensus is displayed. If the devs don't want to waste the time/effort in ensuring that consensus truely was acheived, then there definitely should be some kind of team that would verify it for them.
--Andrew Whitworth
So few projects have arbcoms that it's unreasonable to include specific mention of them into any foundation-wide policy. The current method of asking for a bug is decent, requiring a link to be posted to a page where consensus is displayed. If the devs don't want to waste the time/effort in ensuring that consensus truely was acheived, then there definitely should be some kind of team that would verify it for them.
Devs have been happy to check consensus, but it seems in this case people disagree with the dev's judgement. If people aren't going to accept the dev's judgement, the determination of consensus needs to be done by someone inside the project. The ArbCom is the best option where there is one, where there isn't, a crat would be best. If there isn't a crat, then an admin. The alternative is just letting the devs get on with it and not complaining when they consider a 2/3 majority to be sufficient and you don't.
On Jan 12, 2008 5:55 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
So few projects have arbcoms that it's unreasonable to include specific mention of them into any foundation-wide policy. The current method of asking for a bug is decent, requiring a link to be posted to a page where consensus is displayed. If the devs don't want to waste the time/effort in ensuring that consensus truely was acheived, then there definitely should be some kind of team that would verify it for them.
Devs have been happy to check consensus, but it seems in this case people disagree with the dev's judgement. If people aren't going to accept the dev's judgement, the determination of consensus needs to be done by someone inside the project. The ArbCom is the best option where there is one, where there isn't, a crat would be best. If there isn't a crat, then an admin. The alternative is just letting the devs get on with it and not complaining when they consider a 2/3 majority to be sufficient and you don't.
I can agree with that, bureaucrats tend to be relatively small in number and should be well-versed in determining consensus at their home project. For extremely small projects (ie those without a bureaucrat), consensus should be able to determine directly.
--Andrew Whitworth
Since when has it been ArbCom's job to decide the community's consensus? It seems as though we're trying to expand their job, once again.
Chad
On Jan 12, 2008 5:55 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
So few projects have arbcoms that it's unreasonable to include specific mention of them into any foundation-wide policy. The current method of asking for a bug is decent, requiring a link to be posted to a page where consensus is displayed. If the devs don't want to waste the time/effort in ensuring that consensus truely was acheived, then there definitely should be some kind of team that would verify it for them.
Devs have been happy to check consensus, but it seems in this case people disagree with the dev's judgement. If people aren't going to accept the dev's judgement, the determination of consensus needs to be done by someone inside the project. The ArbCom is the best option where there is one, where there isn't, a crat would be best. If there isn't a crat, then an admin. The alternative is just letting the devs get on with it and not complaining when they consider a 2/3 majority to be sufficient and you don't.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 12/01/2008, Chad innocentkiller@gmail.com wrote:
Since when has it been ArbCom's job to decide the community's consensus? It seems as though we're trying to expand their job, once again.
Yes, it would be a small expansion of their job. Is there really a problem with that? It doesn't come up very often, and all they have to do is come along at the end and decide if there's a consensus or not.
"just letting the devs get on with it and not complaining" may be the best suggestion I've heard so far. Mike.lifeguard
-----Original Message----- From: Thomas Dalton [mailto:thomas.dalton@gmail.com] Sent: January 12, 2008 6:56 PM To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] tech team - content community bottleneck
So few projects have arbcoms that it's unreasonable to include specific mention of them into any foundation-wide policy. The current method of asking for a bug is decent, requiring a link to be posted to a page where consensus is displayed. If the devs don't want to waste the time/effort in ensuring that consensus truely was acheived, then there definitely should be some kind of team that would verify it for them.
Devs have been happy to check consensus, but it seems in this case people disagree with the dev's judgement. If people aren't going to accept the dev's judgement, the determination of consensus needs to be done by someone inside the project. The ArbCom is the best option where there is one, where there isn't, a crat would be best. If there isn't a crat, then an admin. The alternative is just letting the devs get on with it and not complaining when they consider a 2/3 majority to be sufficient and you don't.
Thomas Dalton wrote:
How should the devs know which communities have an Arbcom that needs to approve the bug? I think any system put in here needs to, by default, not interfere with the devs doing their work. Giving communities more opportunities to raise a flag before implementaion is good. But requiring the devs check with X before every implementation, or any process external to Bugzilla, is bad.
The devs only make these kind of changes if someone asks them to, so if the rule is made that only ArbComs (or crats/admins if there is no ArbCom) can make such requests then the devs don't have to check with anyone, they just have to verify that the person asking really is a member of the project's ArbCom, which isn't that difficult. It's certainly easier than trying to work out if there's a consensus for the change.
As far as I know, it is not a role of the arbcom to do such things. It looks weird to add new responsibilities.
Ant
On 13/01/2008, Florence Devouard Anthere9@yahoo.com wrote:
Thomas Dalton wrote:
The devs only make these kind of changes if someone asks them to, so if the rule is made that only ArbComs (or crats/admins if there is no ArbCom) can make such requests then the devs don't have to check with anyone, they just have to verify that the person asking really is a member of the project's ArbCom, which isn't that difficult. It's certainly easier than trying to work out if there's a consensus for the change.
As far as I know, it is not a role of the arbcom to do such things. It looks weird to add new responsibilities.
The en:wp arbcom is not the government of en:wp - it's a body to resolve intractable interpersonal disputes. People keep wanting it to act as the government of en:wp, but it really isn't and can't be.
That said, it keeps getting other functions assigned to it - checkuser, oversight - because there isn't really any other group suitable for the job. This is likely to become another one, which is possibly not a good thing.
- d.
As far as I know, it is not a role of the arbcom to do such things. It looks weird to add new responsibilities.
It's not a role of ArbCom, no, but things can change. I'm suggesting that it become a role. The alternative is to use crats, as determining consensus is definitely part of their role and this is just applying the same skills to another situation. Personally, I'd rather give the job to ArbCom (assuming they don't have any major objections), but it doesn't really make a lot of difference.
Hoi, In a different thread people told me that you can not make people do things. Things can indeed change.. Thanks, GerardM
On Jan 13, 2008 1:12 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
As far as I know, it is not a role of the arbcom to do such things. It looks weird to add new responsibilities.
It's not a role of ArbCom, no, but things can change. I'm suggesting that it become a role. The alternative is to use crats, as determining consensus is definitely part of their role and this is just applying the same skills to another situation. Personally, I'd rather give the job to ArbCom (assuming they don't have any major objections), but it doesn't really make a lot of difference.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 13/01/2008, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, In a different thread people told me that you can not make people do things. Things can indeed change..
I added a parenthetical aside to my comment precisely to address that issue.
You cannot. That's why this is a bad idea. We have an instance of a developer (in good faith!) not determining consensus at the appropriate percentage level (whatever percentage consensus allows this week, sheesh). Saying "ArbCom or Bcrats must review every developer request so they can submit it" is inherently a /bad idea/. I've made quite a few requests for new features, etc...and I didn't ask the en.wiki community first. Under the new system, would that lead to a block? Why can't a well-intentioned user make their own requests, and not have to jump through a million hoops to do so? No one is going to want to fill out a WP:RFARODR (Request for Arbitrator Review of Developer Request) and wait a month for the Arbs to review it just to get stuff done.
It's all adding to the useless bureaucracy.
Always, Chad
On Jan 13, 2008 9:24 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, In a different thread people told me that you can not make people do things. Things can indeed change.. Thanks, GerardM
On Jan 13, 2008 1:12 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
As far as I know, it is not a role of the arbcom to do such things. It looks weird to add new responsibilities.
It's not a role of ArbCom, no, but things can change. I'm suggesting that it become a role. The alternative is to use crats, as determining consensus is definitely part of their role and this is just applying the same skills to another situation. Personally, I'd rather give the job to ArbCom (assuming they don't have any major objections), but it doesn't really make a lot of difference.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
I've made quite a few requests for new features, etc...and I didn't ask the en.wiki community first.
What kind of requests are you talking about? There is a big difference between asking for a change to the site's configuration for user permissions and asking for a new magic word to let you display the latest football results automagically. The former type of requests require community approval and have done for years, the latter kind have nothing to do with the community - the community can, of course, choose not the use them, but deciding what features to add to the code is completely up the developers.
Requests to change how SpecialPage queries are run, to add greater flexibility for sorting. A change that would /most certainly/ affect the community.
Chad
On Jan 13, 2008 3:19 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
I've made quite a few requests for new features, etc...and I didn't ask the en.wiki community first.
What kind of requests are you talking about? There is a big difference between asking for a change to the site's configuration for user permissions and asking for a new magic word to let you display the latest football results automagically. The former type of requests require community approval and have done for years, the latter kind have nothing to do with the community - the community can, of course, choose not the use them, but deciding what features to add to the code is completely up the developers.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 13/01/2008, Chad innocentkiller@gmail.com wrote:
Requests to change how SpecialPage queries are run, to add greater flexibility for sorting. A change that would /most certainly/ affect the community.
Sure, any change will affect the community, that doesn't means it's something that requires community consultation. Adding a few extra sort options to special pages is not going to do any harm, is it? It's also not the kind of change that can be easily made to just one site as it's a change to core code, so you can't get community approval for it, there being no one community to ask.
--- Domas Mituzas midom.lists@gmail.com wrote:
Hello!
And we would do well to refuse doing such thing.
Foundation would
become a huge bottleneck and community will then begin
complaining that we
are hindering the development of the projects.
Well understood and appreciated.
Yesterday I tried to do one tiny tiny change (es.wikipedia wanted to switch their timezone). Of course, after last flames it was fun to make a circus out of it (forced few people - sysops and bureaucrats to 'sign in blood'), but here again, accurately interpreting votes and resolutions in other languages, where there were multiple votes on same page, as well as Great Walls of Text, was nearly impossible.
Lots of things can be rolled forward and backwards, so usually no harm is done - except that it takes time and can cause some frustrations, if caught in the middle of heated debate.
So, we usually have just to trust that people who come and ask for things can really represent community, and are not going to undermine something in evil ways. Usually we like to trust, and love to trust. But sometimes a single campaign against can shatter it all.
-- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
Is there any way for b'crats to automatically put on the e-mail list for any bug filed for their wiki? This combined with a 5-day mandatory waiting period between filing and fixing a bug without the express support of a b'crat should be able to keep things running smoothly.
Birgitte SB
____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Hoi, Have a look at this http://www.mediawiki.org/wiki/Special:SiteMatrix and then ask yourself if your request can be implemented. It sounds nice though. Thanks, GerardM
On Jan 12, 2008 7:35 PM, Birgitte SB birgitte_sb@yahoo.com wrote:
--- Domas Mituzas midom.lists@gmail.com wrote:
Hello!
And we would do well to refuse doing such thing.
Foundation would
become a huge bottleneck and community will then begin
complaining that we
are hindering the development of the projects.
Well understood and appreciated.
Yesterday I tried to do one tiny tiny change (es.wikipedia wanted to switch their timezone). Of course, after last flames it was fun to make a circus out of it (forced few people - sysops and bureaucrats to 'sign in blood'), but here again, accurately interpreting votes and resolutions in other languages, where there were multiple votes on same page, as well as Great Walls of Text, was nearly impossible.
Lots of things can be rolled forward and backwards, so usually no harm is done - except that it takes time and can cause some frustrations, if caught in the middle of heated debate.
So, we usually have just to trust that people who come and ask for things can really represent community, and are not going to undermine something in evil ways. Usually we like to trust, and love to trust. But sometimes a single campaign against can shatter it all.
-- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
Is there any way for b'crats to automatically put on the e-mail list for any bug filed for their wiki? This combined with a 5-day mandatory waiting period between filing and fixing a bug without the express support of a b'crat should be able to keep things running smoothly.
Birgitte SB
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
If the feature is possible, then use the site-notice to ask b'crats to opt-in for it. With such a feature even if they ignore/can't translate that site-notice, every wiki will only have one experience trying to make a complaint before being directed to the sign-up.
I wouldn't expect devs to go through the userrights logs and track down email addresses for all of the b'crats. But I don't know if it is even possible to do if we had all the e-mail addresses.
Birgitte SB
--- Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Have a look at this http://www.mediawiki.org/wiki/Special:SiteMatrix and then ask yourself if your request can be implemented. It sounds nice though. Thanks, GerardM
On Jan 12, 2008 7:35 PM, Birgitte SB birgitte_sb@yahoo.com wrote:
--- Domas Mituzas midom.lists@gmail.com wrote:
Hello!
And we would do well to refuse doing such
thing.
Foundation would
become a huge bottleneck and community will then
begin
complaining that we
are hindering the development of the projects.
Well understood and appreciated.
Yesterday I tried to do one tiny tiny change (es.wikipedia wanted to switch their timezone). Of course, after last flames it was fun to make
a
circus out of it (forced few people - sysops and bureaucrats to
'sign
in blood'), but here again, accurately interpreting votes and resolutions in other languages, where there were multiple votes on
same
page, as well as Great Walls of Text, was nearly impossible.
Lots of things can be rolled forward and
backwards,
so usually no harm is done - except that it takes time and can cause some frustrations, if caught in the middle of heated debate.
So, we usually have just to trust that people
who
come and ask for things can really represent community, and are
not
going to undermine something in evil ways. Usually we like to trust, and love to trust. But sometimes a single campaign against can shatter it all.
-- Domas Mituzas -- http://dammit.lt/ --
[[user:midom]]
Is there any way for b'crats to automatically put
on
the e-mail list for any bug filed for their wiki? This combined with a 5-day mandatory waiting
period
between filing and fixing a bug without the
express
support of a b'crat should be able to keep things running smoothly.
Birgitte SB
____________________________________________________________________________________
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Hoi, Ok let met spell it out.. How many projects do you see ?? Do you really believe that the developers are willing to spend their time on this ? Thanks, GerardM
On Jan 12, 2008 9:29 PM, Birgitte SB birgitte_sb@yahoo.com wrote:
If the feature is possible, then use the site-notice to ask b'crats to opt-in for it. With such a feature even if they ignore/can't translate that site-notice, every wiki will only have one experience trying to make a complaint before being directed to the sign-up.
I wouldn't expect devs to go through the userrights logs and track down email addresses for all of the b'crats. But I don't know if it is even possible to do if we had all the e-mail addresses.
Birgitte SB
--- Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Have a look at this http://www.mediawiki.org/wiki/Special:SiteMatrix and then ask yourself if your request can be implemented. It sounds nice though. Thanks, GerardM
On Jan 12, 2008 7:35 PM, Birgitte SB birgitte_sb@yahoo.com wrote:
--- Domas Mituzas midom.lists@gmail.com wrote:
Hello!
And we would do well to refuse doing such
thing.
Foundation would
become a huge bottleneck and community will then
begin
complaining that we
are hindering the development of the projects.
Well understood and appreciated.
Yesterday I tried to do one tiny tiny change (es.wikipedia wanted to switch their timezone). Of course, after last flames it was fun to make
a
circus out of it (forced few people - sysops and bureaucrats to
'sign
in blood'), but here again, accurately interpreting votes and resolutions in other languages, where there were multiple votes on
same
page, as well as Great Walls of Text, was nearly impossible.
Lots of things can be rolled forward and
backwards,
so usually no harm is done - except that it takes time and can cause some frustrations, if caught in the middle of heated debate.
So, we usually have just to trust that people
who
come and ask for things can really represent community, and are
not
going to undermine something in evil ways. Usually we like to trust, and love to trust. But sometimes a single campaign against can shatter it all.
-- Domas Mituzas -- http://dammit.lt/ --
[[user:midom]]
Is there any way for b'crats to automatically put
on
the e-mail list for any bug filed for their wiki? This combined with a 5-day mandatory waiting
period
between filing and fixing a bug without the
express
support of a b'crat should be able to keep things running smoothly.
Birgitte SB
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
In every business, there /needs/ to be a go-to in between developers and end users, plain and simple. That's not to say that end users are necessarily tech-illiterate, or that the techies can't "dumb it down" for the end users. All it says is that the job of the developer and the community are two different entities looking at different goals. Sometimes (obviously, such as this), there is a communications breakdown in between the two groups. People begin talking past each other, and a lot of information gets lost in the process. In my organization where I work, we have 1 or 2 people per department who's job it is to work with IT. IT goes to them when they need to get tech stuff done within a department, and the departments go to them when they need things from IT.
Such a position would benefit the Foundation, I would think. Someone who is tech-oriented but can still work with the end user (in this case, the communities). Facilitation of new features by developers isn't necessarily hard when the end user makes it clear what they want.
Chad H.
On Jan 11, 2008 12:51 PM, Domas Mituzas midom.lists@gmail.com wrote:
Hi!
Correct me if I'm wrong, but I believe the developer who made the switch is not an employee of the Wikimedia Foundation. Take it to wikitech- l or wikien-l, please.
Well, there is quite a bit of foundation issue here, and I'd like to explaim some general projects bits (that are neither technology, nor single-project related):
See, Jens is not employee, though has been the developer with most community-facing attitude. He has been implementing, at his own will, most of community requests. He is a volunteer, and has been dedicated to our ideals more and longer than most of us. When members of communities decide to attack with "This developer has exhibited extremely poor judgment and a gross disregard for the WIkipedia community" and nobody takes that back or apologizes, it is no fun to continue doing all these small things.
Foundation doesn't really facilitate this process at the moment - it is all left to individual care - both filtering, evaluating if change X would successfully follow all few hundreds policy pages, and implementation, what often requires extensive code review and familiarity of our operating environment. Do note, that community representatives come not only with these changes - various 'oh noes, remove this from site' requests are quite common, and every of them are questionable.
If people will be going to raise such huge flames and attack implementors for actually doing the job, we will really ask foundation to facilitate not only all the evaluation of every request that comes in from communities, but to provide with implementor resources too.
We have far more fun things (our jobs, lives, even wikipedia technology development) to do than go into endless debates with people who favor endless debates, sorry.
-- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Hoi, Should this not be something for the en.wikipedia mailing list.. I do not have a clue what you are talking about, is this bigger then en.wp ? Thanks, GerardM
On Jan 11, 2008 4:37 PM, Nathan nawrich@gmail.com wrote:
Given the hurricane of bullshit that erupted over the rollback right in en.wikipedia after JeLuf made the switch, can someone with the Foundation please direct the developers to switch it back off until some semblance of an agreement can be attained? In the mean time, its a wild and crazy shooting match between admins that is sucking attention away from anything actually consequential.
Nathan
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 11/01/2008, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Should this not be something for the en.wikipedia mailing list.. I do not have a clue what you are talking about, is this bigger then en.wp ? Thanks, GerardM
On Jan 11, 2008 4:37 PM, Nathan nawrich@gmail.com wrote:
Given the hurricane of bullshit that erupted over the rollback right in en.wikipedia after JeLuf made the switch, can someone with the Foundation please direct the developers to switch it back off until some semblance of an agreement can be attained? In the mean time, its a wild and crazy shooting match between admins that is sucking attention away from anything actually consequential.
Nathan
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Yes, this should not be on this list. I don't have a clue why it's here.
I fail to see the need for this. The infighting is not an issue for the Foundation to solve. Actually, the initial massive rush of requests for rollback seems to have significantly slowed down, and I'm not seeing rampant rollback abuse breaking out all over the place. Despite the hysteria, it looks to me as though affairs are starting to settle. There's no need for drastic intervention at this point, especially when many editors are using their new button productively and well.
CM
Odi profanum vulgus et arceo.
Date: Fri, 11 Jan 2008 10:37:46 -0500 From: nawrich@gmail.com To: foundation-l@lists.wikimedia.org Subject: [Foundation-l] Rollbackersaurus attacks en.wiki
Given the hurricane of bullshit that erupted over the rollback right in en.wikipedia after JeLuf made the switch, can someone with the Foundation please direct the developers to switch it back off until some semblance of an agreement can be attained? In the mean time, its a wild and crazy shooting match between admins that is sucking attention away from anything actually consequential.
Nathan
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
_________________________________________________________________ Share what Santa brought you https://www.mycooluncool.com
wikimedia-l@lists.wikimedia.org