| title | layout | work-in-progress | copyrights | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
Bikeshedding |
spec |
true |
|
This is a work-in-progress specification.
Members following this work-in-progress specification MUST NOT use the
unprefixed startbikeshed and endbikeshed requests. Instead, members SHOULD
use the draft/startbikeshed-3 and draft/endbikeshed-3 request names to be
interoperable with other members following a compatible work-in-progress version.
The final version of the specification will use an unprefixed request names.
Bikeshedding is an integral part of the IRCv3 process. However, until now it's been wholly inconsistent and a constant strain on our specification efforts.
This spec introduces a clear, consistent way to bikeshed a topic, methods for extending the length of time that we bikeshed a given topic, and security considerations to keep in mind while doing so.
These methods are intended expressly for standardisation groups.
Bikeshedding is primarily done via IRC, in issues or in pull requests. However, these requests may be used in new mediums such as Slack or Discord when we adopt them.
This section outlines the specific requests that are available to members following this specification.
The draft/startbikeshed-3 request signals that the sending user wishes to bikeshed about a particular topic or aspect of the original work. Example topics are listed below.
The format of a draft/startbikeshed-3 request is listed here:
draft/startbikeshed-3 [color-bg] about the colour of the background
The value of the draft/startbikeshed-3 request is explicitly split into two implicit parts, the human-readable description and the machine-readable label for this (which MUST be treated as an opaque identifier). These labels are not standardised, and are expected to be standardised by the members of the Working Group over time as this specification matures.
The description value of the draft/startbikeshed-3 command MUST be treated as an opaque description (or at least a not-entirely-clear one).
When a member uses this command, it indicates that they wish to bikeshed about a particular topic. Upon seeing this command, each member SHOULD proceed to direct at lesat 80% of discussion on the channel/issue/PR around this topic until everyone has given up hope (and a matching draft/endbikeshed-3 request has been made by a member with appropriate permissions).
TODO: draft/endbikeshed-3 request is to be standardised based on ongoing Working Group discussions.
TODO: The list of topics to bikeshed over is to be standardised based on ongoing Working Group discussions.
For backwards-compatibility with members who do not follow this specification, all bikeshed requests MUST be accompanied by a plaintext, human-readable notice indicating everything which the request itself already indicates.
Members of the WG SHOULD CONSIDER that this practice can reduce the security of the produced specifications, by ensuring that most members will avoid thinking about or considering the issue altogether until it is ratified. As such, when this occurs members SHOULD issue a draft/startbikeshed request regarding the security of the specification, and this bikeshedding session MUST last at least three months.
This section is non-normative.