[Foundation-l] Policy modification (was possible reconsideration)

[Mark Williamson]

...that is neither here nor there. You're sidestepping the discussion
at hand yet again to say the same thing you've said in countless other
messages.

Mark

2008/5/26 Gerard Meijssen <gerard.meijssen at gmail.com>:
> Hoi,
> It is possible to request a code for a revived extinct language. The
> argument in favour of such a code is likely to be adopted by the
> organisations that issue the relevant codes. "Ancient" languages cannot
> start a project because by definition expressions in that language are
> exclusively in the past.
>
> There have been those that say that you can express modern language with old
> terminology. I have asked specialists about this notion and they reject
> this. When you want to learn Ancient Greek you learn the grammar by exercise
> and write new text, you create problems in understanding the vocabulary that
> is part of the language when studying modern text. The WMF is about
> learning, when a project is known to be flawed from its inception, when
> there are methods to make the distinction between the modern and the
> original usage clear, it is unconscionable to accept languages under the
> code defining the language as ancient or extinct when there is a clear route
> of making this difference clear.
>
> When community decision means that this strategy is not explored because of
> a wish not to do this, the community is not listening to arguments and hence
> there is no wish to seek a consensus.
>
> It is not really important if everybody agrees on a policy. I do not happy
> with the way the policy is currently explained. However, I am extremely
> happy with the policy as it means that we do not have to argue all the time.
> Changing the policy in a way that makes it less predictable and observable
> would quickly make the policy largely irrelevant and it would rapidly
> degenerate both the policy and the committee into a dysfunctional state.
> Thanks,
>     GerardM
>
> On Tue, May 27, 2008 at 1:08 AM, Ray Saintonge <saintonge at telus.net> wrote:
>
>> Jesse Plamondon-Willard wrote:
>> > Mark Williamson <node.ue at gmail.com> wrote:
>> >
>> >> I think that if the will of the community goes against the decision of
>> >> the committee, perhaps it is time for the committee to reconsider.
>> >>
>> > I agree that community consensus on the policy should override
>> > committee consensus. However, there was no community consensus; we had
>> > a dozen or two people voicing conflicting opinions and proposals about
>> > whether to keep, remove, or replace that clause in the policy. Where
>> > there is a complete lack of community direction on that clause, I
>> > think it's within the committee's purpose to maintain the current
>> > policy.
>> >
>> Absolutely, assuming that the policy was properly adopted in the first
>> place.  Keeping and removing are clear options, but each proposal to
>> replace needs to be viewed as a separate option.  It's not enough to say
>> that we need to replace something without saying what we want to replace
>> it with.  If the replacers have a conflicting variety of proposals let
>> them work out an agreement among themselves.  In parliamentary procedure
>> this is what the sub-amendment process does.  Only after the
>> sub-amendments have been sorted out does the amendment come up for
>> adoption.
>> > If we were to strike out policy for which there is no community
>> > consensus, the result would be the same because we'd be forced to stop
>> > processing ancient languages until we had a policy under which to do
>> > so. However, I think holding requests in limbo indefinitely is a bad
>> > practice.
>> >
>> >
>> The first expression here seems ambiguous as to whether the original
>> policy had no consensus or the striking out had no consensus.  If there
>> is no policy the processing of each affected language would need to be
>> treated as a separate issue with the full range of the usual arguments
>> being repeated.  I do agree that keeping requests in limbo is bad.
>>
>> Ec
>>
>> _______________________________________________
>> foundation-l mailing list
>> foundation-l at lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>