[Foundation-l] Wikipedia:Office Actions
Peter van Londen
londenp at gmail.com
Wed Apr 25 18:59:06 UTC 2007
2007/4/25, Andre Engels <andreengels op gmail.com>:
>
> 2007/4/25, Peter van Londen <londenp op gmail.com>:
> > I don't see the relevance of your answer.
> > What does that have to do with the fact that this policy is unnecessary
> for
> > many projects, where the Foundation still has some authority left and
> these
> > problems do not occur?
>
> So your idea is to have the policy that when a project accepts
> foundation decisions, it does not need to, but when it doesn't it is
> forced to? If on those projects the foundation has sufficient
> authority left, what is lost by having a policy that states that it
> has?
Because it is yet another rule. My idea is to have only so many rules as
necessary (although I see there is a correlation between the amount of rules
and the scale of the project, but in fact I do not understand why this would
have to be the case). If not necessary: no rules, work with consensus, and
common sense. It used to work like that in the past as well.
> It is just a matter of opinion: if it is not broken: don't try to fix it.
>
> But if you fix it anyway, why not fix it good? Better to repair it
> once and have it right than to have to repair every separate piece
> when it breaks.
In fact it is a EN:WP rule forced on the rest of the projects, without
asking consent or informing the other projects in a proper way.
> Apparently in this example you mention: it is broken, the Foundation lost
> > its authority (so clearly that not even Office works), so fix it there.
> > There is no need to fix it project-wide (certainly when most office
> workers
> > will have knowledge of a few languages like every normal person). This
> > problem seems to be very limited compared to the total projects the
> > Foundation has. Simply asking a steward or representative from that
> certain
> > community will do in most cases and will be better accepted by the
> smaller
> > communities, than someone they don't know removes a part of their
> content.
>
> If that does work, then that's the way to go, sure. But what if it
> doesn't on a certain occasion? Say to the project "You won't listen,
> so you're under the policy now"? That is really no different from
> having it under the policy in the first place. Or are we going to
> solve each such occasion separately, so that in a few years time
> before doing an office action on zh:wiktionary the foundation first
> has to check how things work there?
Hypothetically, this might be the case: the reality says it is not much of a
problem outside EN:WP. Trust the trusted user (that is what a
admin/bureaucrat/steward is) to do the right thing in case something like
this happens.
Let's just have a policy that states that these actions can be done,
> and then, when it is needed, they can be done. As long as there are
> other ways that work better, yes, let's use them by all means, but
> there's no reason to close the door on a specific route.
>
> > In some issues it is better to have it fixed at the top. In this case
> not: I
> > would use the network of stewards and other people in stead of forcing
> it
> > upon the project instead.
>
> If the Foundation has legal reason to remove something, then it must
> be able to force it on the project. Whether through the network or by
> other means. This should be no "would you please". How it is done can
> be debated, not whether it should be possible.
agreed. no difference of opinion here, only I would recommend to use the
peoples network. It is still better that someone from the community does the
deletion than someone else, users from the community do not know and are in
fact no member of the community (certainly when this policy is unknown, not
many community members read and use meta).
--
> Andre Engels, andreengels op gmail.com
> ICQ: 6260644 -- Skype: a_engels
>
> _______________________________________________
Kind regards Londenp
foundation-l mailing list
> foundation-l op lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>
More information about the foundation-l
mailing list