ircv3-ideas
ircv3-ideas copied to clipboard
ircv3
Denote the target audience for certain specifications.
Some specifications are more aimed at private networks than existing public and popular ones, indicating the target audience in the specification would help provide a little bit more context.
Normalizing this process would help.
What's the advantage of specifying a target audience in a specification? The specifications should be written such that they are not limited to a certain subset of use-cases. While mentioning a target audience may help clarify the intended usage, it can have the effect of being perceived as a recommendation for when it should/shouldn't be used.
I feel biasing a specification towards a particular usage may push people away from implementing it against the intended use, even if it's a feature they want to support and is within the technical possibilities. The example from IRC, ircv3/ircv3-specifications#292, was discussed as being primarily for bouncers due to concerns about IRCD-level logging of user messages and that is a valid personal concern but not ultimately something that should play into the specification itself. Although users may not like it, networks are free to log content to implement the spec.
The specifications should focus on functionality and technical aspects as opposed to what we believe their best uses are, which is subjective and has little bearing on the ability to implement the spec. Use case discussions are better kept as part of the discussion in comments and IRC, without being written into the specs themselves.
The point is that ircds are still free to use and implement whichever part is in the specification, but that IRCv3 gets a lot of requests from private networks for certain features they want to make possible -- but can't (easily) push through because it generates a lot of controversy because people start applying examples they know from "current IRC", and that's logical thinking on their side.
As ircv3 board you could either ignore those people saying "they don't know what they're doing", or clarify that the spec was written to help those private networks or bouncers, and while still applicable for public ones, is not the intended target audience.
Personally speaking, if I saw the ircv3 team merging a lot of specifications that generally have a reasonable amount of people against it (despite any of them being stakeholders), I'd still look at IRCv3 and think "these guys don't know what they're doing". While they're working with and for the stakeholders, ultimately the people would be using it.
As-is, I can't be in favour of supporting CHATHISTORY because of this, however I am totally in support of the issue if it clarified that this is primarily to benefit private networks and bouncers. If more people are happy with the PR, it can get merged easier with less hassle, and we already have a non-normative part of the specification that's generally considered "the authors opinion" anyways.
I understand that this maybe should not be part of the specification itself, it could be a small bit of metadata at the top e.g. "target: bouncer, private" and "target: public"
Ultimately, many issues are stagnating because people can't support them as it will ruin "irc as we know it", and while I don't entirely take that side, I'm still opposed to the merging of the specification. The excuse has always been "we're writing specs so it is possible, not because everyone should use them", but that's not a very good rationale as some networks will still apply it.
Some sort of note saying "this is intended for private networks" could make ircd authors consider whether channel modes are needed to prevent the use of this feature without directly saying "this should have channel mode $x" (and going even further away from what a specification should be).
I could see something like this. I'll probably look at incorporating this in some way, at least for those that we should be adding these sort of notes to.
Convieniently, someone just left the following comment showcasing why I think this is useful, and I think this metadata/note would have prevented the hassle:
https://github.com/ircv3/ircv3-specifications/pull/289#issuecomment-272413251
<@jwheare> Zarthus: i think it should just be clearly explained in each spec's motivation
section, no need for a specific metadata key
<Zarthus> i thought frontmatter keys were less of an annoyance to deal with than just
writing it, but okay
<@jwheare> freeform allows it to be included where it makes sense along with
justification/context. just like all the other freeform stuff.
<Zarthus> makes sense
