[Framework-Team] Re: random thought: identify the components that lack owners
Wichert Akkerman wrote: Previously Martin Aspeli wrote: For example, I think we are missing a trick currently with the way we manage maintenance releases. We do a good job of setting deadlines and not missing them by too much. What we don't do, is build any sense of urgency or importance around getting things done for those deadlines. We give people windows to hit if they happen to have something in progress. This consists of one or two emails to the list. That's only half the story though. We need to think much more constructively about the process people go about in getting something going in the first place, and encouraging that. I'm hoping that plonenext can help a bit with that. If people make a new release the release manager can include that in plonenext, which makes it immediately available to people developing against that. I have long wanted a way to motivate people to make releases when they are ready instead of only when I send out a call for releases. I'm hoping plonenext will help with that. plonenext will definitely help with that, but that wasn't quite what I meant. This still assumes that people are actually in the middle of working on something that they want to release. Now, of course that happens some of the time, when there are external drivers, such as customer projects that spin off generic components. However, we are not doing enough to get people to start working on contributions in good time. On past experience, there are a few things that make this happen: - Setting a deadline. This is a necessary, but not a sufficient, condition. No-one does anything unless there's a deadline. However, by the time the deadline is set, it's usually too late to *start* working on something, so something has to be in progress (conversely, the deadline is too far in the future, it doesn't feel like a deadline and gets forgotten about). I think this is in danger of happening for 3.3. Ask how many people feel like there's a deadline coming up, and ask how many people feel they have a responsibility to get something done for that deadline. I suspect you won't get many replies. - Setting a shared vision. I think this is what Jon is talking about. We have talked about (and have even put into practice) having loosely defined themes for a release, e.g. 3.2 is the eggs release. These discussions tend to be led by a few people, e.g. you (Wichert), Alex, Hanno, me. I think possibly could have some conventions for making these discussions happen, e.g. a way to propose and then discuss themes. By the way, I suggest we call Plone 4.0 Snow Plone (like Snow Leopard, geddit?). - Following up. Ask people how they're getting on. Make them feel like what they're doing actually matters to other people. Alex has done this in the past, but this is a bit too ad-hoc. The framework team could feasibly do this for submitted PLIPs, but there's often a need to do this before we have PLIPs also. I think this process has to be informal, but we should encourage more of it. - Lavish praise. If someone does something for Plone out of their spare time, be that to fix a bug, contribute a feature, do some pre-release testing, or documentation, or whatever - make them understand that their contributions are appreciated by the whole community. If someone makes a mistake, don't shoot them down for it, but rather try to be constructive and appreciate that their feelings probably will be hurt if we revert their changes. Sometimes we have to, of course, but the way in which that message is delivered is an important determinant for whether that person contributes again. - Sprints! Making the best use of sprints is vital. We tend to lurch forward during a sprint. The ideal sprint, IMHO, is one that has a clear goal (the Baarn sprints have been great like that) and an appropriate mix of people who are motivated to work towards that goal. We then find that 80% of the functionality gets completed at the sprint, and the remaining 20% gets done later. We've talked a bit about aligning releases to sprints. We should probably do it the other way too: align sprints to releases, or at least to desirable releases. For example, we could say that our aim is to have a UI Sprint each year for each release, and a Release sprint just before each release to squash bugs and tidy up loose ends, and then an RD Sprint once a year or so to try out crazy things. I don't think that overly formalising sprints will help (or work), but we can probably just structure what we have slightly better. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP 239: Adapterise the Extensible Indexable Object Wrapper
I'd like to propose the following PLIP for 3.3: http://plone.org/products/plone/roadmap/239 This is about making it easier to have custom indexing strategies on a per-type basis rather than having a global registry of functions. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: random thought: identify the components that lack owners
Previously Martin Aspeli wrote: Wichert Akkerman wrote: Previously Martin Aspeli wrote: For example, I think we are missing a trick currently with the way we manage maintenance releases. We do a good job of setting deadlines and not missing them by too much. What we don't do, is build any sense of urgency or importance around getting things done for those deadlines. We give people windows to hit if they happen to have something in progress. This consists of one or two emails to the list. That's only half the story though. We need to think much more constructively about the process people go about in getting something going in the first place, and encouraging that. I'm hoping that plonenext can help a bit with that. If people make a new release the release manager can include that in plonenext, which makes it immediately available to people developing against that. I have long wanted a way to motivate people to make releases when they are ready instead of only when I send out a call for releases. I'm hoping plonenext will help with that. plonenext will definitely help with that, but that wasn't quite what I meant. This still assumes that people are actually in the middle of working on something that they want to release. Sure. Perhaps my view is a bit slanted because I am always working in several different things at any point in time. Now, of course that happens some of the time, when there are external drivers, such as customer projects that spin off generic components. However, we are not doing enough to get people to start working on contributions in good time. On past experience, there are a few things that make this happen: - Setting a deadline. This is a necessary, but not a sufficient, condition. No-one does anything unless there's a deadline. However, by the time the deadline is set, it's usually too late to *start* working on something, so something has to be in progress (conversely, the deadline is too far in the future, it doesn't feel like a deadline and gets forgotten about). I think this is in danger of happening for 3.3. Ask how many people feel like there's a deadline coming up, and ask how many people feel they have a responsibility to get something done for that deadline. I suspect you won't get many replies. Deadlines are one of those things that you can't live without even though you don't like them. - Setting a shared vision. I think this is what Jon is talking about. We have talked about (and have even put into practice) having loosely defined themes for a release, e.g. 3.2 is the eggs release. These discussions tend to be led by a few people, e.g. you (Wichert), Alex, Hanno, me. I think possibly could have some conventions for making these discussions happen, e.g. a way to propose and then discuss themes. I suspect there is a lot of shared vision, but that we are not very good at writing it down. Partially because we are afraid to since it might look more like a dictate, and partially because we have no good process for it. I think emergent visions are fine, but I do think we need to set some solid directions. I just wrote down a few pages on directions that I think we need to look at and mailed those to the developers list. By the way, I suggest we call Plone 4.0 Snow Plone (like Snow Leopard, geddit?). I don't get it.. The naming for Plone releases has always been a mystery to me but luckily we never actually use those names anyway. I don't know why we bother :) - Following up. Ask people how they're getting on. Make them feel like what they're doing actually matters to other people. Alex has done this in the past, but this is a bit too ad-hoc. The framework team could feasibly do this for submitted PLIPs, but there's often a need to do this before we have PLIPs also. I think this process has to be informal, but we should encourage more of it. - Lavish praise. If someone does something for Plone out of their spare time, be that to fix a bug, contribute a feature, do some pre-release testing, or documentation, or whatever - make them understand that their contributions are appreciated by the whole community. If someone makes a mistake, don't shoot them down for it, but rather try to be constructive and appreciate that their feelings probably will be hurt if we revert their changes. Sometimes we have to, of course, but the way in which that message is delivered is an important determinant for whether that person contributes again. I know I am not always the most subtle person out there. It might be a cultural thing - we tend to be more direct here. You do touch on something important though: we have almost no after-merge process. There is no process for QA testing, writing or updating documentation for changes, getting press and praise out, etc. This is becoming more and more critical now that there is a growing number of projects that share some of the
[Framework-Team] Re: random thought: identify the components that lack owners
Hi Wichert, Deadlines are one of those things that you can't live without even though you don't like them. True. That's why I say necessary, but not sufficient. However, as we've talked about before, I would prefer a slightly more consultative approach in setting deadlines. Sometimes that's hard, because you almost have to force people into the discussion. However, if the FWT and the community feel they had some part in actually setting the deadline, they're more likely to respect it. - Setting a shared vision. I think this is what Jon is talking about. We have talked about (and have even put into practice) having loosely defined themes for a release, e.g. 3.2 is the eggs release. These discussions tend to be led by a few people, e.g. you (Wichert), Alex, Hanno, me. I think possibly could have some conventions for making these discussions happen, e.g. a way to propose and then discuss themes. I suspect there is a lot of shared vision, but that we are not very good at writing it down. Partially because we are afraid to since it might look more like a dictate, and partially because we have no good process for it. I think emergent visions are fine, but I do think we need to set some solid directions. Couldn't agree more. :) I just wrote down a few pages on directions that I think we need to look at and mailed those to the developers list. That's excellent! I think we should encourage more of that kind of thing. By the way, I suggest we call Plone 4.0 Snow Plone (like Snow Leopard, geddit?). I don't get it.. The naming for Plone releases has always been a mystery to me but luckily we never actually use those names anyway. I don't know why we bother :) Heh, my point was more that we should think about what Apple are doing with Snow Leopard: trimming the fat. - Lavish praise. If someone does something for Plone out of their spare time, be that to fix a bug, contribute a feature, do some pre-release testing, or documentation, or whatever - make them understand that their contributions are appreciated by the whole community. If someone makes a mistake, don't shoot them down for it, but rather try to be constructive and appreciate that their feelings probably will be hurt if we revert their changes. Sometimes we have to, of course, but the way in which that message is delivered is an important determinant for whether that person contributes again. I know I am not always the most subtle person out there. It might be a cultural thing - we tend to be more direct here. You don't say... ;-) I think we all need to be doubly aware of who we're talking to when we have a community as diverse as this. You do touch on something important though: we have almost no after-merge process. There is no process for QA testing, writing or updating documentation for changes, getting press and praise out, etc. This is becoming more and more critical now that there is a growing number of projects that share some of the problem/solution space that Plone is in. An awful tool with excellent documentation will almost always win over an awesome tool with lousy documentation. We have come a long way, but we still have many miles to go. Yeah, this is very important. I think it does tend to happen around releases, but mainly because you and Limi do it. I have tried to align releases with events last year. It doesn't work: there are too many and occasionally to move as well. We do have an alignment with this years Plone conference: a Plone 3.2 pre-release (good marketing) and PLIP review for 3.3 (excellent discussion ground) Yep. I think this is something to aspire to rather than something we can do in absolute terms. Still, not wanting to sound like a broken record, but there's no point in setting a deadline if (a) people don't have enough forewarning to get themselves organised; or (b) we don't encourage people to organised, but rather rely on the deadline to do that indirectly. That means things like what you just did on plone-dev - setting a vision; and it means asking people when they expect to be working on something and giving them a say (though not a veto) on deadlines and schedules - within reason, of course. I don't think that overly formalising sprints will help (or work), but we can probably just structure what we have slightly better. I feel we need better sprints: fewer people, smaller focus, try harder to get people with the right experience and long-term availability in and make sure we get people with outside expertise in. I think there are two types of sprints: Those that are organised and those that are just for fun. We shouldn't (and can't) stop people from getting together and doing nothing useful at all. After all, we don't own them. But when it comes to things like adjusting release schedules, opening a window for travel scholarships and so on, we can probably demand certain types of sprints. Just something as simple as a stated goal, by
[Framework-Team] who owns what, according to trac
Scratching my own itch (thanks to Hanno for suggesting I look at the component owner list in trac), I pulled together this list of current component owners, sorted into owned and unowned. COMPONENTS WITH TRAC OWNERS Archetypes nouri Catalogwitsch Content Rules optilude Control Panel hannosch Image Blob Support witsch Installer (Mac OS X) smcmahon Installer (Unified)smcmahon Installer (Windows)dreamcatcher Intelligenttextmaurits Internationalization hannosch Javascript mj KSS (Ajax) ree Linkintegrity witsch Lockingjfroche Navigation/Folder listings optilude NuPlone Theme limi OpenID support davisagli Portlets optilude Search witsch Spelling Error hannosch Transforms hannosch Versioning alecm Visual Editor (Kupu) duncan WebDAV dreamcatcher COMPONENTS WITH NO TRAC OWNERS ATReferenceBrowserWidget Accessibility Calendar and time Content Types Discussions Documentation Infrastructure (kind of a broad area) Login and registration Mail MimetypesRegistry Permissions RSS RTL Upgrade/Migration Usability (also a pretty broad area) Users/Groups Visual and templates Wiki support (Wicked) Workflow Working copy support (Iterate) MY QUESTIONS: Are there owned components where the owner is not active? Are there unowned components that are actually owned? Which unowned components are the most critical to get owners for? Are there unnamed components that need owners? Are there unnamed components that have owners? Should I take this discussion out to the dev list? ;-) :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: who owns what, according to trac
Jon Stahl wrote: Scratching my own itch (thanks to Hanno for suggesting I look at the component owner list in trac), I pulled together this list of current component owners, sorted into owned and unowned. COMPONENTS WITH TRAC OWNERS Archetypes nouri I wonder how effectively Daniel can manage this, given that it's such a big piece of code. It'd be good to make sure we can form out bugs here to others as needed. Catalogwitsch Content Rules optilude Control Panel hannosch Image Blob Support witsch Installer (Mac OS X) smcmahon Installer (Unified)smcmahon Installer (Windows)dreamcatcher Intelligenttextmaurits Internationalization hannosch Javascript mj KSS (Ajax) ree Linkintegrity witsch Lockingjfroche Navigation/Folder listings optilude I really wish I could give this to someone else... I don't own this in any meaningful way, and I think I become a bottleneck. NuPlone Theme limi Limi is probably a bottleneck here. Unfortunately, we struggle to find people willing to own template/visual bugs. OpenID support davisagli Portlets optilude Search witsch Spelling Error hannosch Transforms hannosch Versioning alecm Visual Editor (Kupu) duncan WebDAV dreamcatcher This one tends to bottleneck, because not enough people know very much about WebDAV. COMPONENTS WITH NO TRAC OWNERS ATReferenceBrowserWidget Accessibility Calendar and time Content Types This one really should have an owner, since it's so fundamental. Discussions Documentation Infrastructure (kind of a broad area) Right, we should rationalise this away. Login and registration This one badly needs an owner. I think Wichert was looking after it, but realised he couldn't keep up. Mail MimetypesRegistry Permissions RSS RTL Upgrade/Migration Usability (also a pretty broad area) Users/Groups Ditto - I think Wichert gave up on this one. Visual and templates This one is huge, and used to be Limi's. Wiki support (Wicked) Workflow Working copy support (Iterate) MY QUESTIONS: Are there owned components where the owner is not active? Are there unowned components that are actually owned? Which unowned components are the most critical to get owners for? See above. Are there unnamed components that need owners? Are there unnamed components that have owners? Should I take this discussion out to the dev list? ;-) Please! If we can define what a component owner does, we can probably recruit some more. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: random thought: identify the components that lack owners
Thanks to you both for lots of great writing, this is really helpful. I'm pretty much in 100% agreement on what you've written so far — so don't take my silence as anything but consent at the moment. Battling US immigration authorities in Brazil to try to get back to the US, so my time is limited at the moment. :) Wanted to comment on one particular subject that was mentioned: On Sun, 28 Sep 2008 09:10:23 -0300, Wichert Akkerman [EMAIL PROTECTED] wrote: I feel we need better sprints: fewer people, smaller focus, try harder to get people with the right experience and long-term availability in and make sure we get people with outside expertise in. I agree, and I think we should also arrange more sprints that are less of the travel somewhere and see the world type. Local sprints (see SuperHappyDevHouse etc for inspiration) are really valuable, and there are several natural pockets of Plone developers around the world — San Francisco, Amsterdam, Oslo (well, Tønsberg ;) and more. A local 1-2 day event — during the week or the weekend — can go far in getting some real work done, and I'm planning to do one with Steve McMahon and Joel Burton (or at least one of them) and others here in San Francisco as soon as possible. Related, World Plone Day might offer some useful insights on these pockets and the potential for local sprints. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
