Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128642 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 6EFFB1A00BC for ; Fri, 5 Sep 2025 12:17:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1757074567; bh=17hxWBBMWPMOhyyJP/U5QDqTt4TVtu9x5Eqspwq6H3Q=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=Qkp4rWau+y8AdbNIsnGv0Uga+QFFjAlqanOb4VWXnqY2vEV076Vk0CHE8Dd9RUwo3 zPnUwE9mOhOAMFp/fo80nl0OQdRPGtqnEO8Xg5aNCqK6wwSpG0aEVL6vHxhIrP/qE4 ExTOniRIG4Yj+kZ7KCu+6m+yEHRsmFetip8Z7+W1IOuQoiiXzMd7j5W2C1neMyaLGf jj67NQ534/KVF23TCpFfemLiK4boWrHEFlOWbhHKbNj45+0wtUk+gMocuJRoiKOqXW qsdBA4GUzoP7YiotumQisiEv35t6771a1gZX0cKzLX6ISWTk2FO4eQYCWNMpcE1e/V ydgj7O5+S68ZQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 833BA18006E for ; Fri, 5 Sep 2025 12:16:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from fhigh-a3-smtp.messagingengine.com (fhigh-a3-smtp.messagingengine.com [103.168.172.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 5 Sep 2025 12:16:05 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 462CC14003DB; Fri, 5 Sep 2025 08:17:33 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-05.internal (MEProxy); Fri, 05 Sep 2025 08:17:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1757074653; x= 1757161053; bh=3iR6ObHg8G1k6Md1dUqGD0anJZS+ceXQCoSdlrgA24Q=; b=G coEeXGs5cwFPnBKchUDFccRytUkhAIt33KGfIAQy3AoMWhs++sJXHJ8C7pDfPxMk ubg/LXcCg9p9vqfnlZc5w7wTrOJtGMutFNwruc1unFbDvo+rMH/4mLwVG5Nr54Ce /2Szs4eHABJsHOczw2ksCC+hgzENIEawPb2oG68/kR/sP+eO1Ze2Kn7pPE+0Z6BV BnPekyAbS8dbtoLrkUdFCl0DAPiBStMvllYw1if1jb97ebu3qZzeiI8pjDz9NqGj qCInFejxjO70blEPYp6axJjK8leJ8LTswoa5Q0lLIRu4gKmFM7duVKQfKurmQVcU vTT028nn4VElg4uo6Z4PA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1757074653; x=1757161053; bh=3iR6ObHg8G1k6Md1dUqGD0anJZS+ceXQCoS dlrgA24Q=; b=Lmr/JM3MYJdA1IfPEpTREherufd6qmdnrjORdTMTjGvlad0I+0A AsmrZGvHsL15pt+BIXWS1pBVIoIl/bxQ1Td/cYaRKsbjqiwC+yLhD2lr7RP5aO4i 4ysRVNvCp6xs+1mBfhD1DBZy3c3sisbJYf4VBnLO/u1nhhDFieNvtCI7aTKvHDQp fhSl4zI48S/HzGQmdl4xLO2kZ0LEH2Q1mX5ln8b0mj1ZSBQz7e2lRVEd9tDFjrke gq0zw50yU2r51imnnHK1UJMhzKyZn7bUXRauPd/moIVfumSAjlg1L4xj7DduVqXu cfwfGllc9b7l7qxzFzreAAAFkvUfffV17mQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdekkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epofggfffhvfevkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfnrghn uggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtthgvrh hnpefffffgffduieelhedvgeeftdeufeegheefgfehvdelkeeufeefffeltdeijeehtden ucffohhmrghinhepvgigthgvrhhnrghlshdrihhonecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvshdp nhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepthhimh essggrshhtvghlshhtuhdrsggvpdhrtghpthhtoheplhgrrhhrhiesghgrrhhfihgvlhgu thgvtghhrdgtohhmpdhrtghpthhtohepihhnthgvrhhnrghlsheslhhishhtshdrphhhph drnhgvth X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 879F8182007E; Fri, 5 Sep 2025 08:17:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: AyNXb5nLmdzs Date: Fri, 05 Sep 2025 14:17:12 +0200 To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: "Larry Garfield" , "php internals" Message-ID: <2a947796-bba1-4587-8e89-4c946b300c25@app.fastmail.com> In-Reply-To: References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be> <4624748F-0C62-4E3C-81D0-5CDC56FEC55F@nicksdot.dev> <68c44ae3-8e1b-419d-9c30-906b9c2d5a81@app.fastmail.com> <0f32efec-b6c9-4ec0-96bf-297da722aaf1@bastelstu.be> <7ab7580d355569eed3d69aec92dacd4c@bastelstu.be> <73866cf1-6ac9-4e30-9273-0634cea43352@app.fastmail.com> Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules Content-Type: multipart/alternative; boundary=0d7a2322f6e446f6a6856a8302e3386b From: rob@bottled.codes ("Rob Landers") --0d7a2322f6e446f6a6856a8302e3386b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 5, 2025, at 12:22, Tim D=C3=BCsterhus wrote: > Hi >=20 > Am 2025-09-04 20:17, schrieb Rob Landers: > >> Specifically =E2=80=9COther RFCs=E2=80=9D (i.e. RFCs that do not to= uch the language, > >> which is not actually defined) =E2=80=9Cmight=E2=80=9D (this probab= ly should read=20 > >> =E2=80=9Cmay=E2=80=9D) > >> use a =E2=80=9Csmaller timeframe=E2=80=9D that =E2=80=9Cshould be a= t least a week=E2=80=9D (i.e. it=20 > >> may > >> also be 2 hours). In other words, that policy is completely useless= to > >> resolve any cases of disagreement, since it allows basically anythi= ng. > >=20 > > So, someone could create an RFC, saying "Jo ElePHant, III" is=20 > > "President of PHP", set the voting period for exactly one minute, vo= te=20 > > on it themselves, and close the vote, and whomever "Jo ElePHant, III= "=20 > > is, would have to be the President of PHP before the announcement em= ail=20 > > is even delivered to the entire list? >=20 > That is my understanding of the current policy, yes. =F0=9F=98=AD >=20 > > Somehow I doubt this would actually fly, despite "maybe, technically= ",=20 > > being within the rules. >=20 > Sure. It would also possible to follow-up with a new =E2=80=9Cproper=E2= =80=9D RFC that=20 > reverses the previous decision. You were using an extreme example, but=20 > we a case in PHP 8.5 where the discussion period arguably was cut shor= t:=20 > https://externals.io/message/128040#128272 >=20 > > I think the more you make a policy pedantic, the easier it is to pla= y=20 > > pedantic games. I had a couple of hours to sit on the train and thin= k=20 > > through some loopholes in the current proposed text: > >=20 > > 1. The 336 hours is oddly specifc. It also begs the question: "what=20 > > about leap seconds?" Could someone cause an entire revote simply by=20 > > pointing out that the vote closed one second earlier than 336 hours=20 > > because one of those hours had one less second? Does it matter? Perh= aps=20 > > saying "~336 hours" to drive the intent home without saying "exactly= "=20 > > that amount of time? >=20 > An hour is well-defined to be 3600 seconds. Leap seconds are a concept=20 > of =E2=80=9Cdate and time=E2=80=9D, but do not affect how much time ha= s actually passed.=20 > After 2035 there will be no more leap seconds and given the slowing of=20 > Earth's rotation it seems unlikely to have any more leap second. In an= y=20 > case it is easy for an RFC author to completely bypass this question b= y=20 > treating the specified lengths of time as minimums, which is likely to=20 > implicitly happen anyways. The widget requires you to specify a datetime that it ends on, not a dur= ation. Meaning the time between the two week dates is not guaranteed to = always be exactly 336 hours, even in UTC. If there is a leap second, it = would be 335:59:59 hours between the two dates, possibly unbeknownst to = the person setting up the voting widget. Someone wanting to invalidate t= he vote (or whatever the penalty is), could then do so and be within the= ir rights. >=20 > > 2. Just about any change could be construed as an "obvious typo" or=20 > > "editorializing" A stronger definition could be "any change that=20 > > clarifies but does not alter the meaning (e.g. "frrm" -> "from" but = not=20 > > "form" -> "from"), while changes that affect APIs, semantics, or=20 > > options are never typos". Even then, someone could just create a stu= b=20 > > and simply argue that all their edits are clarifying the stub... so=20 > > this one will be tricky. >=20 > I believe this is sufficiently handled by the =E2=80=9Cwhen in doubt t= reat it as=20 > a more significant change=E2=80=9D and the list of examples of what co= nstitutes=20 > a major or minor change. The proposed policy specifically says that=20 > =E2=80=9Cclarification=E2=80=9D is a minor change and that anything th= at would lead to a=20 > change in implementation is a major change. Right, but who is doing the doubting? There isn't a defined arbiter, thu= s it can be a battle of the wills: someone on the list claiming it is a = significant change vs. (potentially multiple) authors who disagree. Some= one needs to be able to say "this is significant" and make that decision= binding. >=20 > > 3. Forbidding starting/ending on Dec 17->Jan 10 will probably=20 > > backfire. It would behoove someone to schedule a voting start on Dec=20 > > 16, so that it would end on Jan 11. Albeit, that is longer than 2=20 > > weeks, but it's shorter than waiting until Jan 11 to start a vote...=20 > > arguably, this is probably worse than what the rule intends to solve= .=20 > > If the concern is holiday churn (heh, uninitentional rhyming), it mi= ght=20 > > be better to forbid *starting* during that period, but let existing=20 > > votes play out as normal (and maybe picking a sooner date). >=20 > Starting on December 16 and ending on January 11 would be fine for me.=20 > I've intentionally added some buffer space so that anyone interested i= n=20 > participating in the RFC process should find the time to cast their vo= te=20 > after they followed the RFC discussion and thus had the opportunity to=20 > make up their mind. Besides =E2=80=9CNew Year=E2=80=99s=E2=80=9D and =E2= =80=9CChristmas=E2=80=9D, I've=20 > specifically also accounted for Eastern Christianity Christmas (releva= nt=20 > for Russia) which is on January 7th. Interesting. It's probably fine then. I just wanted to point out that th= ere could be unforseen consequences with people rushing to get to a vote= before that period, resulting in less quality RFCs vs. waiting. >=20 > > 4. The official start and threading is ambiguous. For example, I ca= n=20 > > add a coauthor on my RFC. Then "announce" the RFC by both authors bu= t=20 > > only have discussions in the later thread. I could move to a vote af= ter=20 > > two weeks, no matter what is happening in another "unofficial" threa= d. >=20 > I'm afraid I don't understand what you are trying to say here. It said that an RFC timing is bound to a thread starting with a specific= subject. Both authors could create two separate threads, one that is "u= nofficial" but looks official, and the other "official" thread that no c= onversation happens on. Since no conversation has occurred on the "offic= ial" thread, they could just start a vote after two weeks and technicall= y not violate the rules (assuming they made no significant changes to th= e RFC). We see this often where the pre-discussion thread outlives the o= fficial announcement thread, for example; and they're not even being mal= icious. In this case, the RFC author wouldn't be bound by the cooloff pe= riods at all. >=20 > > 5. It says that you can't add or change a voting widget, but you ca= n=20 > > remove them freely without triggering a vote reset. >=20 > Removing is the most extreme form of changing one, but I can certainly=20 > spell that out explicitly. >=20 > > 6. It might be a good idea to add "all durations are measured in UT= C=20 > > calendar time, ignoring leap seconds". One could argue that announci= ng=20 > > the vote at 11:59:59 Monday and starting the vote at 00:00:01 Wednes= day=20 > > would satisfy the 2 day/48 hour rule by arguing time zone shenanigan= s. >=20 > The hour-based definition is already independent of any timezones. Vote starts are based on a specific time, usually with the local time of= the email in the headers. It doesn't explicitely and unambiguously say = these are durations in a specific timezone, but implies it. One extreme = example would be to say that 2 days had passed somewhere in the universe= with a different flow of time relative to our local space. >=20 > > 7. If a vote ends at 15:09, does it actually ends at 15:09:00, or w= ill=20 > > votes be accepted until 15:09:59.99? >=20 > I'm happy to clarify this in the policy. Similarly to deadlines in the=20 > real world this would be understood =E2=80=9Cuntil, but not including=E2= =80=9D, i.e. as=20 > long as the clock doesn't show 15:09. >=20 > > 8. vote extension hack: can someone change a vote end-date after th= e=20 > > vote has already started? Thus if the results are unfavorible, can I=20 > > simply just extend the voting period until I get the results I want,=20 > > literally increasing it by 24 hours every day until it passes by sim= ply=20 > > stating "I am still on holiday"? >=20 > No. The end date must clearly be specified in the email announcing the=20 > vote. You are free to select a longer interval right away, but once th= e=20 > vote started, the decision is locked in. I can spell it out more=20 > explicitly that the RFC (including the voting rules) may no longer=20 > change once the vote started. >=20 > > The new rules could allow some creative people to bypass the cooldow= n=20 > > period altogether: > > 1. Someone could create an empty RFC, and announce it. Then "clarif= y"=20 > > and "editorialize" the RFC (easier to do with a coauthor to back you=20 > > up) minutes before the two weeks elapse, then call a vote, with most=20 > > people having long dismissed the empty RFC as junk. >=20 > I believe I answered that with bullet point (2) above. >=20 > > 2. You could simply create a v2 of an RFC minutes/days after the=20 > > failed vote and go straight to a vote; claiming the cooldown started=20 > > from the original RFC. >=20 > I don't see how that would be possible even with an intentionally=20 > =E2=80=9Cmalicious=E2=80=9D reading of the policy. The policy specifie= s that the=20 > discussion period of an RFC starts with the official RFC discussion=20 > thread matching the title of the RFC and linking the Wiki page. Thus a= ny=20 > existing discussion clearly is not applicable to a newly created RFC. >=20 > Best regards > Tim D=C3=BCsterhus =E2=80=94 Rob --0d7a2322f6e446f6a6856a8302e3386b Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 5, 2025, at 12:22, Tim D=C3=BCsterhus wrot= e:
Hi

Am 2025-09-04 20:17, schrieb Rob Landers:
>= > Specifically =E2=80=9COther RFCs=E2=80=9D (i.e. RFCs that do not to= uch the language,
>> which is not actually defined) =E2=80= =9Cmight=E2=80=9D (this probably should read 
>> =E2= =80=9Cmay=E2=80=9D)
>> use a =E2=80=9Csmaller timeframe=E2= =80=9D that =E2=80=9Cshould be at least a week=E2=80=9D (i.e. it 
>> may
>> also be 2 hours). In other word= s, that policy is completely useless to
>> resolve any c= ases of disagreement, since it allows basically anything.
>=  
> So, someone could create an RFC, saying "Jo ElePHa= nt, III" is 
> "President of PHP", set the voting peri= od for exactly one minute, vote 
> on it themselves, a= nd close the vote, and whomever "Jo ElePHant, III" 
> = is, would have to be the President of PHP before the announcement email&= nbsp;
> is even delivered to the entire list?
That is my understanding of the current policy, yes.

=F0=9F=98=AD


> Somehow = I doubt this would actually fly, despite "maybe, technically", 
> being within the rules.

Sure. It wo= uld also possible to follow-up with a new =E2=80=9Cproper=E2=80=9D RFC t= hat 
reverses the previous decision. You were using an ex= treme example, but 
we a case in PHP 8.5 where the discus= sion period arguably was cut short: 

> I think the more you make a poli= cy pedantic, the easier it is to play 
> pedantic game= s. I had a couple of hours to sit on the train and think 
> through some loopholes in the current proposed text:
>= ; 
>  1. The 336 hours is oddly specifc. It also = begs the question: "what 
> about leap seconds?" Could= someone cause an entire revote simply by 
> pointing = out that the vote closed one second earlier than 336 hours 
> because one of those hours had one less second? Does it matter? = Perhaps 
> saying "~336 hours" to drive the intent hom= e without saying "exactly" 
> that amount of time?

An hour is well-defined to be 3600 seconds. Leap s= econds are a concept 
of =E2=80=9Cdate and time=E2=80=9D,= but do not affect how much time has actually passed. 
Af= ter 2035 there will be no more leap seconds and given the slowing of&nbs= p;
Earth's rotation it seems unlikely to have any more leap se= cond. In any 
case it is easy for an RFC author to comple= tely bypass this question by 
treating the specified leng= ths of time as minimums, which is likely to 
implicitly h= appen anyways.

The widget requires= you to specify a datetime that it ends on, not a duration. Meaning the = time between the two week dates is not guaranteed to always be exactly 3= 36 hours, even in UTC. If there is a leap second, it would be 335:59:59 = hours between the two dates, possibly unbeknownst to the person setting = up the voting widget. Someone wanting to invalidate the vote (or whateve= r the penalty is), could then do so and be within their rights.


>  2. Just about any change could be construed as an "obv= ious typo" or 
> "editorializing" A stronger definitio= n could be "any change that 
> clarifies but does not = alter the meaning (e.g. "frrm" -> "from" but not 
>= "form" -> "from"), while changes that affect APIs, semantics, or&nbs= p;
> options are never typos". Even then, someone could jus= t create a stub 
> and simply argue that all their edi= ts are clarifying the stub... so 
> this one will be t= ricky.

I believe this is sufficiently handled b= y the =E2=80=9Cwhen in doubt treat it as 
a more signific= ant change=E2=80=9D and the list of examples of what constitutes 
a major or minor change. The proposed policy specifically says = that 
=E2=80=9Cclarification=E2=80=9D is a minor change a= nd that anything that would lead to a 
change in implemen= tation is a major change.

Right, b= ut who is doing the doubting? There isn't a defined arbiter, thus it can= be a battle of the wills: someone on the list claiming it is a signific= ant change vs. (potentially multiple) authors who disagree. Someone need= s to be able to say "this is significant" and make that decision binding= .


>  3. Forbidding starting/ending on Dec 17->= Jan 10 will probably 
> backfire. It would behoove som= eone to schedule a voting start on Dec 
> 16, so that = it would end on Jan 11. Albeit, that is longer than 2 
&g= t; weeks, but it's shorter than waiting until Jan 11 to start a vote...&= nbsp;
> arguably, this is probably worse than what the rule= intends to solve. 
> If the concern is holiday churn = (heh, uninitentional rhyming), it might 
> be better t= o forbid *starting* during that period, but let existing 
> votes play out as normal (and maybe picking a sooner date).<= div>
Starting on December 16 and ending on January 11 woul= d be fine for me. 
I've intentionally added some buffer s= pace so that anyone interested in 
participating in the R= FC process should find the time to cast their vote 
after= they followed the RFC discussion and thus had the opportunity to <= /div>
make up their mind. Besides =E2=80=9CNew Year=E2=80=99s=E2=80=9D= and =E2=80=9CChristmas=E2=80=9D, I've 
specifically also= accounted for Eastern Christianity Christmas (relevant 
= for Russia) which is on January 7th.

Interesting. It's probably fine then. I just wanted to point out that= there could be unforseen consequences with people rushing to get to a v= ote before that period, resulting in less quality RFCs vs. waiting.


=
>  4. The official start and threading is ambiguous. = For example, I can 
> add a coauthor on my RFC. Then "= announce" the RFC by both authors but 
> only have dis= cussions in the later thread. I could move to a vote after 
> two weeks, no matter what is happening in another "unofficial" t= hread.

I'm afraid I don't understand what you a= re trying to say here.

It said tha= t an RFC timing is bound to a thread starting with a specific subject. B= oth authors could create two separate threads, one that is "unofficial" = but looks official, and the other "official" thread that no conversation= happens on. Since no conversation has occurred on the "official" thread= , they could just start a vote after two weeks and technically not viola= te the rules (assuming they made no significant changes to the RFC). We = see this often where the pre-discussion thread outlives the official ann= ouncement thread, for example; and they're not even being malicious. In = this case, the RFC author wouldn't be bound by the cooloff periods at al= l.


>  5. It says that you can't add or change a v= oting widget, but you can 
> remove them freely withou= t triggering a vote reset.

Removing is the most= extreme form of changing one, but I can certainly 
spell= that out explicitly.

>  6. It might be= a good idea to add "all durations are measured in UTC 
&= gt; calendar time, ignoring leap seconds". One could argue that announci= ng 
> the vote at 11:59:59 Monday and starting the vot= e at 00:00:01 Wednesday 
> would satisfy the 2 day/48 = hour rule by arguing time zone shenanigans.

The= hour-based definition is already independent of any timezones.

Vote starts are based on a specific time, = usually with the local time of the email in the headers. It doesn't expl= icitely and unambiguously say these are durations in a specific timezone= , but implies it. One extreme example would be to say that 2 days had pa= ssed somewhere in the universe with a different flow of time relative to= our local space.


>  7. If a vote ends at 15:09, = does it actually ends at 15:09:00, or will 
> votes be= accepted until 15:09:59.99?

I'm happy to clari= fy this in the policy. Similarly to deadlines in the 
rea= l world this would be understood =E2=80=9Cuntil, but not including=E2=80= =9D, i.e. as 
long as the clock doesn't show 15:09.
=

>  8. vote extension hack: can someone chang= e a vote end-date after the 
> vote has already starte= d? Thus if the results are unfavorible, can I 
> simpl= y just extend the voting period until I get the results I want, 
> literally increasing it by 24 hours every day until it pass= es by simply 
> stating "I am still on holiday"?
=

No. The end date must clearly be specified in the em= ail announcing the 
vote. You are free to select a longer= interval right away, but once the 
vote started, the dec= ision is locked in. I can spell it out more 
explicitly t= hat the RFC (including the voting rules) may no longer 
c= hange once the vote started.

> The new rules= could allow some creative people to bypass the cooldown 
> period altogether:
>  1. Someone could create an= empty RFC, and announce it. Then "clarify" 
> and "ed= itorialize" the RFC (easier to do with a coauthor to back you 
> up) minutes before the two weeks elapse, then call a vote, wi= th most 
> people having long dismissed the empty RFC = as junk.

I believe I answered that with bullet = point (2) above.

>  2. You could simply= create a v2 of an RFC minutes/days after the 
> faile= d vote and go straight to a vote; claiming the cooldown started 
> from the original RFC.

I don't see= how that would be possible even with an intentionally 
=E2= =80=9Cmalicious=E2=80=9D reading of the policy. The policy specifies tha= t the 
discussion period of an RFC starts with the offici= al RFC discussion 
thread matching the title of the RFC a= nd linking the Wiki page. Thus any 
existing discussion c= learly is not applicable to a newly created RFC.

Best regards
Tim D=C3=BCsterhus
<= br>
=E2=80=94 Rob
--0d7a2322f6e446f6a6856a8302e3386b--