[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