Post
It’s cool to see this (working groups) happen organically: https://news-web.php.net/php.internals/129447
I’ve had a draft RFC for this concept sitting around for a while, but I wasn’t sure whether it would be welcome. https://wiki.php.net/rfc/working_groups
@ramsey In practice *every* RFC already has a working group. It's roughly 5-10 folks participating in the discussion of any individual RFC with the RFC author(s) leading the discussion and making the final decisions.
@ramsey And from what I've seen, newcomers on the list receive a friendly welcome, their questions are answered and any (honest) mistakes - most notably top-posting and quoting mistakes - are remarked while still answering their email.
@timwolla I am not proposing that WGs be created for the purpose of drafting RFCs at all.
@ramsey That's not really a working group, as much as "let's argue the same as on the list, but on GitHub instead."
A proper working group has a dedicated set of experts whose opinions/perspectives matter more than other people's. What Edmond is doing is... not that.
@Crell Agreed. See my response to @derickr: https://phpc.social/@ramsey/115612014107992314
To be clear, by “whether it would be welcome,” I’m not implying anyone would be hostile to it, but feedback I’ve gotten has been along the lines of, “What is the use-case?”
I think we now have a real-world use-case, instead of hypotheticals.
@ramsey I came to the same conclusion about the importance of an initial charter a few days ago in this message: https://externals.io/message/129300#129351
I think something that's different between this situation and the examples in your RFC draft is that the WG would be working towards a single goal, and most of its work would be released all at once when that goal was met.
That makes defining when the wider community is consulted trickier: too few voting opportunities, and the WG can spend months delivering something that gets declined; too many, and the WG becomes ineffective.
@ramsey Something I see definite value in is allowing votes on partial plans, with the WG committed to tackling the open issues.
The example in this thread of debating whether something should extend Error or Exception really brought home to me that the normal RFC process actively encourages bikeshedding, because a Yes vote is considered unconditional approval of a final design.
@ramsey My comment on the "call for working group" explains my big issue with it:
«I believe this "working group" already starts on the wrong foot with even the definition of "Stage 1".
Its first purpose ought to be: "What is the most single basic thing for most of the PHP users."
…
Launching straight into the intricacies of implementation isn't a constructive way forward, IMO.»
https://github.com/true-async/php-true-async-rfc/discussions/8#discussioncomment-15078769
@derickr I agree, which is why I think a WG needs a clearly defined and community-approved (via RFC) charter. (See my RFC.)
A space for Bonfire maintainers and contributors to communicate
