On Saturday, August 6, 2016 at 11:43:51 AM UTC-6, Matthieu Napoli wrote: > I like that project (FIG 3.0) a lot, however I'm also concerned that only > 12 people will vote on PSRs. What if there's a PSR being written that has > nothing to do with those 12 people? > > For example what if there's an "async" PSR but none of those 12 people > work with async libraries: why would they vote YES? And also important: why > would they be "qualified" enough to vote correctly on topics they may not > work with? -> both technically and in terms of seeing/understanding the > need behind the PSR (hope I'm not offending anyone in saying that, that's > not the goal at all) >
This seems to be an incorrect - though common - interpretation of the WG and CC implementation proposed above. As I understand it, from reading the TL;DR, the comments on the ML, and the actual FIG 3.0 bylaws themselves, the 12-member CC doesn't actually vote on the content of the PSR. Instead, the Working Groups vote on the technical content of a PSR, while the Core Committee votes on whether the PSR went through the correct processes completely, and can therefore be considered finalized. The CC's understanding of the spec itself isn't strictly relevant to their vote, because they aren't voting on the content, beyond a high-level quality-assurance evaluation. Instead, they're voting on whether the WG properly considered input from all interested parties, whether the spec is properly presented in accordance with FIG conventions, whether the required number of implementations exist, and similar. This is all done *after* the technical considerations have been voted on by the WG (and if the WG doesn't already contain all interested/affected parties in its own right, the FIG Member Projects at large, as described earlier by Michael), and that vote has passed. So by the time the CC sees it, the technical content should already have been vetted. Said another way, the WG is responsible for the technical vote; the CC is responsible for the process vote. Or as an analogy, the WG is the developers, while the CC is quality assurance. I'm not really seeing a conflict, here, in having the WG/CC voting process be set up the way it is. ---- Regarding the "ownership" concern brought up by others in this thread, I think formalizing the "informal vote of member projects" that Michael mentioned above *into* the process (by which I mean, adding it to the FIG 3.0 bylaws, in writing) would probably address this concern, by making clear that such a vote is expected in these cases? Is that a valid conclusion? I imagine the WG would be responsible for taking this step, as described above, and if it isn't completed before the CC vote, they would be obligated to reject the PSR until that vote has been cast and considered. At which point, the WG could resubmit the PSR for further evaluation and approval. (I imagine the vote results, along with major concerns expressed therein, and so forth, would be included in the meta document?) I could see a case or two crop up where the WG doesn't realize their PSR covers other member projects in the first place, and only discovering that fact after sending the PSR to the CC for approval. But I also expect the CC would point this out during the initial acceptance vote on whether a PSR should even be created, if the WG didn't already note such scope in their proposal. - Daniel Hunsaker -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5e6f9a3f-089f-447a-bf15-be89ef70387e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
