[Framework-Team] Re: Release roadmap for 3.0
Martin Aspeli
optilude at gmx.net
Thu May 11 07:47:35 UTC 2006
On Thu, 11 May 2006 08:06:30 +0100, Rob Miller
<ra at burningman.com> wrote:
> it's okay.. i've cooled off. i'm sorry for flying off the handle.
To be honest, re-reading my post, I completely understand how it would be
taken that way.
>>>> Whether it's wearing the framework team hat or not at any given point
>>>> in time is moot.
>>>
>>> no, it's not.
>> It isn't? Our names are well-known, and so is our task - to vote PLIP
>> bundles in or out of a release (with the release manager having the
>> final say). Do you not think people will gauge our reactions when we
>> participate in the community outside this list?
>
> this is the part i feel most strongly about. i think that it is very
> important that everyone, especially you in the spokesperson role, make it
> quite clear when they're speaking as a representative of the framework
> team,
> as distinct from the general case of just speaking for themself. of
> course,
> the opinion that a framework team member, even speaking as himself, has
> about
> the value of a particular effort, which someone hopes to get into a
> specific
> release, is going to be important.
I absolutely agree.
> the framework team was created with a very specific and limited role,
> deliberately. that role is to assess the technological impact of the
> proposals that are presented. there IS a need for the cheerleading, the
> cat-herding, the discussion-driving, the hand-holding, the (gentle)
> nay-saying, etc. but that's not what the people who are on this team
> were
> asked to do. if they want to, taking OFF their hats as members of the
> team,
> then great... i'm 110% in support of that.
...
> that may be. i think you do a great job of communicating what you think
> is
> important to the community, and taking a strong role in shepherding
> people
> along. i strongly encourage you to keep on doing this, and would even
> support
> the existence of some structure around that. but, IMNSHO, it's not the
> framework team.
Right. Again, though, I'd argue that there is a feeling "out there" that
it possibly should be the role of the framework team, at least to some
limited extent, because it is known that we vote what goes in our out at
the end of the day. (actually, a long time ago when the team was first
formed and up until the bundle freeze for 2.5, I thought this was its
primary role - guess I should've read the announcements more carefully!).
If the "shepherding team" said, go do this, it's great, and the framework
team quielty thought, there's no way, but we'll make our decision at
bundle time (obviously an exaggerated example) then that could be pretty
damaging. So by not having any such shepherding team, which by its
non-existence can't talk to the framework team about how decisions are
likely to swing, we risk people mis-interpreting the signs of senior
community members being encouraging, perhaps even more so if those members
are also on the framework team.
Let's put it another way. When a bundle comes in, it's a proof of
concept-and-direction. We can't accept only 100% completed work, because
then no-one would take the risk to complete it lest it were rejected or
very trivial. I believe this is made clear in the process documentation as
well. So our decision is based naturally around two criteria: desirability
and risk.
Desirability will depend on where we (with the complete input of the Plone
community at large) feel that Plone is going. So, I'd vote down a bundle
that gave Plone a 100% Flash UI because I don't think it's a particularly
great idea, even if the implementation was rock solid, but I'd vote up an
AJAX-driven UI (if done right of course) because I think it's something we
really need to stay competitive.
Risk depends on whether we trust the submitting people to be able to get
it done, either alone or with the help of the community. The degree of
risk and the type of features we are willing to accept will depend on
marketing (where does the Foundation, limi and the community think Plone
needs to go to stay competitive). It will depend on our experience with
the people involved (i.e. if you said you'd get something done, I'd trust
you based on your previous track record, more than somone I didn't know or
someone who's known to let things slip). It will depend on what else is
going on, are there better solutions in the work, will Zope/CMF invent
similar solutions very soon?
That process starts now - it starts with the list of PLIPs that we can all
read and think about, with the implementors that we can all speak to. We
will as a matter of course keep track of what's going on in the lists and
in svn. But it feels strangely non-transparent to me if we are to not
acknowledge that, and simply frame our existence in the few weeks right
after the bundle deadline, and hide our decisions behind purely technical
arguments. Some features *are* more important than others, and our
decisions will most definitely be influenced, whether explicitly or
implicitly, by that fact. And conversely, if all of us were quietly
praying for a given contributor to get his act together and finish
something, because it seems to fit into the overall agenda of the release,
would we not want to be as encouraging as we could?
>> I think the framework team is too much tied to the six-month release
>> cycle for that to be their primary target; perhaps it's the role of the
>> release manager, perhaps we need no-one to do it at all, and people
>> just naturally align themselves with where the community is going. But
>> I think that it's naive to assume that, realistically, socially we who
>> have been given any kind of official title at all (the framework team,
>> the release manager, the foundation executive) will have no impact
>> whatsoever on where people see Plone going, where they're willing to
>> put the hours in, and what they are support ideologically.
>
> of course it's naive. but the framework team is a revolving door.
> anyone
> who's following what's going on in the plone community well enough to
> know who
> the members of the framework team are is probably also going to be aware
> who
> most of the respected members of our community are. what we need is for
> discussion of things to be happening on plone-devel among ALL of these
> people,
> so the general sense of where we want to head (and where we don't) is
> plain to
> everybody, before folks are faced with the formality of the PLIP-bundle
> process. and, yes, it would be nice to have someone driving that
> discussion.
That's absolutely right. I guess we're kind of saying the same thing from
different angles - there is a lot of scope for this to be misunderstood.
Someone asking for direction, where do I put my time in, will this
investment of my spare time pay off, will want some degree of certainty
that what they're doing won't just be thrown away. Talk to Paul Everitt
about that, I know he's put some effort and even gotten someone to put
money into some things that ultimately gained no take-up, when he was
under the impression that the community old guard were behind it.
Regardless of the merits of that work (and I'm not familiar with the
particular situations because most of them happened before my time), I
know that he has at times felt pretty disillusioned about either beging
misled or at the very least just not being led at all. Paul is an
interesting example because he has a lot to contribute in terms of
technical ideas, not just marketing, but he is not as involved in the
technical side of the community as we are and can't judge the pulse of
where things are going as well as we would. I think we need a way of
dealing with contributions like his. If someone's waving money (or time)
in front of us and say, you can have this, but I want to know that it's
not being wasted, well... then we better have an answer for them! And
since the buck apparently stops with the framework team and the release
manager, those people will be assumed to be somewhat accountable.
Does that matter? There is a very strong argument that open source is
Darwinian, and things exist in the wild backed by whomever is willing to
back them, until they are proven good enough for wider adoption. I support
that model completely, but if it comes to a point where someone says, I
could do this, but I'm not interested in doing it unless I have some
guarantee that it's even interesting (and by extension, eligible for
inclusion if the qualitify is sufficiently high, as opposed to purely
based on the merits of the idea itself)... then where do they go? We may
not have the luxery of waiting for those people to get paid for that work
anyway, or to simply hope they'll take the plunge and spend all their
weekeends on something and then happily accept that actually, we didn't
really want that. In most instances, the reactions on plone-dev and the
collective wisdom of the community will be enough to steer that process
early on, but when there is disagreement, how do we arbitrate? How do we
get on top of that situation before it gets out of control and ends up
with a lot of disillusioned contributors?
> ironically, however, this whole exchange is an example of how that can
> work.
> i got upset because i interpreted your message as a definitive statement
> about
> what the role of the framework team should be, rather than as one
> opening up a
> discussion on that topic.
Yes, I got that. Thanks again for pointing it out. :)
>> I hope that clears some of it up.
>
> it does. so, for the record, i'm a strong +1 on there being some persons
> taking on the role of driving discussion on the devel list about what
> should
> and shouldn't land in the next release, and on who's gonna do what,
> cheerleading, all that. i'll definitely take part in such discussions,
> and
> will provide support as i can.
>
> and i'm a strong -1 on this being thought of as an official role of the
> framework team. in fact, i think that any overlap between whoever is on
> the
> framework team and whoever is driving the discussions and managing the
> process
> should be thought of as purely coincidental.
I think those are good points, and I certainly agree with the merits of
having that separation be clear. I just wonder whether we truly *can* have
such a separation, and whether there then is a vacuum in leadership and
policy guidance that we need to fill, because I think people are expecting
more than what we're expecting to give at the moment.
Martin
--
"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006
More information about the Framework-Team
mailing list