On 08/29/2016 10:50 AM, GeeH wrote:
I have a few points I'd like to raise here - thanks to all involved in
pull vote this time around. Obviously, all of the below comments are
my opinions, and should be taken as such.
## Mission Statement
I really dislike it. I would prefer something short and catchy than
this statement which I think is woolly and doesn't really tell anyone
anything. I would prefer something like "Promoting good standards in
PHP", something short that immediately tells people what this new FIG
is about, rather than I don't think the mission statement needs to
worry about how the mission is achieved (others will disagree here,
and that's fine). This is the kind of overwritten statement I've come
to hate.
A mission statement should be concise, I agree, but not so short that it
is meaningless. It defines scope, and a metric by which we can judge
whether our actions are "in scope". "Promote good standards" doesn't
really help define scope. The proposed mission is 3 sentences, which is
shorter than many I've seen. :-)
How would you suggest shortening it, while still keeping the essence
intact? (promote good standards, collaborate, publish PSRs, based on a
combination of old and new.)
## Secretaries
- Acting throughout their term essentially as Developer Advocates for
the PHP FIG
I believe the this is out of the scope of a secretary of the FIG, and
should be removed, I see no need for a competent secretary to submit
talks on the FIG, blog about it, or promote it in any way.
This is included in the bylaws around the Secretary role now. We left
that essentially intact as changing the secretary role we considered
mostly out of scope.
That said, I could see that role as less relevant with the CC, who could
easily serve the same role. With a more focused set of people involved
the need for specific dev advocates is smaller, as (presumably) many CC
members would also be submitting sessions and talking up FIG and
advocating for collaboration and such.
I'm open to removing that clause if others are.
I would also like to see some accountability added into the
secretaries role so that phrases like "we have been dealing with this
behind the scenes" become a thing of the past. I'd like to see
publically visible records of email chains sent by the secretaries on
behalf of the FIG, and records of other conversations. While this may
seem like we are not trusting the secretaries, it's certainly not a
matter of trust for me. It's a case of everyone being able to see
exactly what is going on, so efforts are not duplicated, and surprises
are never seen when discussions are raised on this list. If
secretaries are having discussions on the interpretation of a bylaw,
for example, that discussion should be visible to the members they
represent in my opinon.
While I can appreciate the spirit here, I am very skeptical about
forbidding non-public conversation. It's often extremely useful for
people to talk privately to diffuse a situation, or handle something
that is mundane and boring. I would hate to see regular IRC chat logs
dumped onto the list; that's just meaningless noise. And if I knew I
couldn't talk to a Secretary without the conversation becoming part of
the public record, well... I would never talk to a Secretary, which is a
pretty terrible situation to be in.
And what of CC members? Should they be disallowed from having private
conversations, too? Once again, that's an excellent way to ensure the
job can't be done correctly.
I've found, repeatedly, that having an "audience" is the best way to
ensure that people are NOT reasonable. When people have an audience,
they feel the need to "stand their ground" more, defend their position,
and in a sense "perform". Forced-public logs also encourages shaming,
or discouraging people from discussing sensitive matters if they fear
public embarrassment (rightly or wrongly).
Basically, forbidding private conversation castrates the ability of
someone to do their job.
So what level of "reporting" by the Secretaries would be needed, while
still respecting the very real need to allow humans to have private
conversations when appropriate?
## Working Groups
### Sponsors
"A PSR must be sponsored by a member of the Core Committee."
Why? Only 12 people can be sponsors of PSRs? Why can't member projects
sponsor PSRs anymore? I don't understand what this brings to the table
apart from shrinking the pool of people who may sponsor a PSR.
One of the goals of FIG 3 is to shift the workload from 40-ish people
who are by and large not paying attention to a dozen people we can
require to pay attention because that's explicitly their job. Yes, this
does reduce the importance of projects in favor of the elected Core
Committee, who is chosen by those active in FIG matters generally, not
just project leads. That's deliberate and by design, because the
correlation between "is the owner of a project on GitHub that someone is
using" and "has the time, energy, skill, and temperament to design,
review, and coordinate standards" is, as we've seen, extremely weak.
As we have only 8 Coordinators now (as the current Sponsor and
Coordinator basically fold together into a single role in FIG 3), I
don't think that's really a problem in terms of availability.
## Votes
"A secretary may trigger any type of vote if appropriate and necessary."
I disagree, only Core Committee members and Project Representatives
should be able to call a vote after the mandatory discussion period. I
would like to see all votes have a mandatory two week minimum
discussion period marked with a set titled thread such as [Discussion].
We deliberately avoided specifying the mechanics of specific list
subject lines, and in fact removed a few. With the active discussion of
splitting the list into multiple lists (which I personally support) or
switching to a forum (which I do not support) and so on, it seemed wise
to leave those mechanics to be defined by the secretaries as needed.
That said, I'm totally open to adding a requirement that most votes
should have a 2 week notice before they start. (I don't think a
Referendum needs one, for instance.) The caveat there being that,
basically, *nothing* gets done in less than a month. (2 week
discussion, 2 week vote.) Are we OK with that implication?
Michael felt strongly about Secretaries being able to call a vote on
FIG's behalf, so I will let him respond to that point. (Although he's
traveling at the moment so may not be quick about it.)
Overall
I'm undecided, this still doesn't feel like a great idea to me, but I
have nothing better to offer and accept that something needs to
change. I'm particularly worried about the Core Committee, basically,
the 12 most popular people will be voted into a position of power in
the FIG, and under the current implementation, only those 12 will be
able to sponsor a PSR. This feels confusing to me. It also feels that
the member projects take a big back-seat role then, only able to vote
in secretaries and core committee members. Of course, this doesn't
preclude them from being involved in working groups at all, but really
their job is only to decide who staffs the various roles if I'm
reading this right (on second reading, that might be a good thing). I
also think that two years seems like a hell of a long period for
someone to be voted onto the core committee - I would prefer to see
this reduced to a maximum of one year.
As noted above, yes, the intent is to shift the focus from projects to
the CC and Working Groups. In a sense, we're putting the emphasis on 12
"Community Reps" (Cal's old job) rather than project reps in particular.
The tension between "people and projects" is still unresolved in
practice, despite the bylaws having resolved it years ago. Project reps
today are *supposed* to be just a representative of their project, but
as PMJ likes to point out at every opportunity that doesn't stop most
people from voting on the applying person, not the applying project.
And to be fair, as noted earlier, the skill-set of "represent the
interests of my project" and "ensure a high level of quality and
consistency across a variety of specs" are not always the same. In fact
they're frequently different, and someone being good at one doesn't mean
they'd be any good at the other, or vice versa. And there are plenty of
people who would be excellent for the CC that are not affiliated with a
particular project. The current effective filter that "you're only cool
enough if you're a project lead, and if you're a project lead you must
be cool enough" is in practice a very bad one. :-)
The result is that it's already effectively a popularity contest, just
with a project flag waving behind it. That's the status quo.
FIG 3 decouples "project lead or their proxy" from "qualified and
trusted to pay attention to and reviewing every spec in detail". That
resolves the "people vs project" question by splitting it in half;
project reps can genuinely be about the project, and CC members can
genuinely be about the person.
I will also note project reps are explicitly allowed to also be on the
CC. That's deliberate. If someone is up to the task of both, and is
comfortable wearing both hats, so be it. In practice, I expect
somewhere around half of the CC will also be project reps. I am
entirely OK with that.
As for the length of the term, we wanted to have a stagged term like
secretaries do and for the same continuity reasons. We also didn't want
too short a term, as then we'd spent all our time having elections.
(Remember, elections are a month long process.) One election every 8
months seems about as frequent as I think we can stomach, which gives a
2 year term. The logic is the same as for secretaries. I don't know
how to shorten it without making CC members spend all their time
thinking about the next election, even in the most benevolent way.
(Think Senate vs House of Representatives, for the United Statesians in
the audience.)
I may have missed it, but there doesn't appear to be anywhere that
regulates the location that working groups should have discussions.
I'm all for letting the working groups have their own communication
methods, but it should be public and have a historical record
somewhere for everyone to read. It should also be made clear where
discussions take place on the website (or in the README of the PSR) so
finding these places are easy, and anyone can later read what
discussion happened. Let's take this opportunity to get more
transparency all around.
You didn't miss it; we didn't address that part directly. The closest
there is would be this clause:
" The Secretaries will ensure that the Working Group is provided with
necessary resources to work on the specification, such as a dedicated
GitHub repository, mailing list, forum section, and similar such tools."
The intent of which is to explicitly allow Git repos in the FIG GitHub
organization, extra mailing lists, etc. Something to keep it under the
FIG umbrella, where there is (hopefully) more visibility.
Micro-specifying how WGs work internally didn't seem wise at this point,
although I fully agree that we should be nudging them toward more
discoverable mechanisms. (A list per PSR, or cluster of related PSRs
like 15 and 17, would be my preference but I know others disagree.)
Further refining the WG workflow seems like something we should
follow-up on later, once the dust has settled a bit.
Kudos to Larry and Michael for all the hard work you both did in
getting this to the table.
Thanks!
--Larry Garfield
--
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/b19fb934-91e5-e6bc-28fa-99a5c6687162%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
