home contents changes options help subscribe

last edited 1 year ago by Christian Theune

Zope Summit 2010 Summary

This document was compiled from the notes and index cards written during the formal part of the summit by Christian Theune.

Contents

The retrospective

Themes

These are the themes that were assembled from the input after we thought about the high points we had as Zope developers in our past.

Better presentation
  • "Spread the word"
  • Share experiences (success stories)
  • more visibility
  • UI esthetics
  • ZMI
Vision/Roadmap
  • Functional areas
  • Leader/maintainer
  • Status and goals
  • Library lifecycle
Developer friendliness
  • "Frustration free"
  • Fun (all the way down)
  • Pythonic
  • keep an open mind
  • better exchange with Python community
Quality
  • Mature developers
  • Passion (good or bad?)
  • Working with like-minded people
  • Professionalism
  • Attention to details
  • Quality code
  • Excellence
Sprints
  • more Sprints
  • SPRINTS!
Be thoughtful
  • Thoughtful collaboration
  • Be nice!
  • respect ideas of others
  • Community is more important than technology
  • protect and build friendships
Modular reuse
  • ZODB
  • CMF
  • Client and server components
  • Component architecture (within limits)
Newcomers
  • Beginner friendliness
Creative and open to new ideas
  • Sprints are creative
  • Focus on the problem (not the solution)
  • Creativity
  • Too much maintenance (Creativity vs Maintenance)
  • Leveraging lessons learned in other areas
  • No winners, no loosers
  • Open to new ideas
Make it understandable
  • Better documentation and [clear]? intentions
  • Understanding intentions (Why does this do this?)
  • Easy to understand
  • Too many unanswered mail questions
  • high level overview

Goals

The following goals were derived from the themes to have specific tasks that will help us improveme our story in those themes. They have been drafted and selected to adhere to the SMART (specific, measurable, attainable, relevant and timely) principle.

ZopeSprints2011
Christian Theune Will try to find topics and interested people for dedicated sprints in 2011 until the end of 2010. Will also organize broader Zope sprints and EuroPython and PyCon in 2011.
Community facilitator project
Jan-Wijbrand Kolman
IRC/mailinglist rationalisation
Wolfgang Schnerring
Zope ideas mailinglist
Martijn Faassen
View from 10k feet (The core Zope concepts)
Albertas Agejevas
Survey why users join/stay/leave Zope
Patrick Gerken
Developer guide
Charlie Clark aiming to have something by end of 2010. Can be nagged on this.
Improve test setup performance
Florian Friesdorf
Fix cryptic error messages
Marius Gedminas
Synopsis of every package in the ZTK
Martijn Faassen
Switch to webob
Jim Fulton
Define ZTK functional areas
Thomas Lotze, aiming to have a set of areas that has already seen some community discussion by the end of October 2010.
Get 3 or more vision statements from individuals
Wolfgang Schnerring
Survey which groups of newcomers we want to cater to
Patrick Gerken

Wrap-up

When finishing the first day we ended with room for appreciations and some ways to put out questions/criticism about the retrospective itself. I'm paraphrasing from my notes.

Some people were puzzled about not having gotten any new information. Some were missing more concrete technical discussions and goals. Others wondered how we're going to talk about technical issues.

There were specifically complaints that the technical discussions and the hard questions were missing. The latter resulted in a round of gathering the hard questions and the decision to have a time-boxed discussion on the second day. The strict process was found to be a waste of time by some people, others found it wasn't enforced strictly enough. The goals should have been improved further after they were presented by the working groups.

Looking forward and asking for hopes, the participants said they wanted to discuss more technical tasks and goals (specifically JavaScript). They also hoped to confront the "hard stuff". "Lets do software."

"The hard questions"

We took time on the second day to discuss the so-called "hard questions" that were raised at the end of the first day.

The questions centered around: "What is the future Zope?", "What is the Zope community about?", "What do we want to be about?", "How much code can we share?"

Here's the notes from the conclusions that everyone gave:

  • Pick functional areas to work on and organize the sprints around them and build enthusiasm around it.
  • It's not about the code base but a community of people you like to work with.
  • Get new people that bring in fresh energy.
  • A shared vocabulary helps collaboration.
  • Define Zope around principles instead of "code" or "solutions". Build sub-communities and bridges.
  • There is value (and opportunity) in consolidating.
  • We're a mature community that (still) has opportunities.
  • Worries about losing commitment from individuals.
  • Diverging and collaborating with the outside is a sign of maturity.
  • Quality of software has a value in itself.
  • We should have topic-driven time-based sprints.

Notes from after the retrospective

As the second day didn't come to a specific conclusion and some of the discussions were quite heated I'll give a list of the things I noted over the day. Some of them are semi-quotes, I marked those with quote-signs (").

Also this can just be an excerpt of what I heard in the individual discussions. Please feel invited to discuss those and add what you heard in the discussions you've been involved with.

  • "Zope 2 is just a tiny piece of the eco system."
  • Martijn emphasized that he's looking for doing creative things and inspiration.
  • How do we deal with javascript fractioning?
  • Discoverability is sometimes missing, the idea of "polish the gems" seems to be connected to that.
  • 1 single person is not going to step up for leading the community
  • Maybe more focus on community: provide venues for exchanging ideas, probably in non-physical ways (to allow participation for people that are far away and to allow this to happen more often)
  • For things we love: make it easy for people who consider using it to find out why and how they want to use it.
  • 1. Instability hinders innovation. 2. Breaking backwards-compatibility stifles stability. 3. Go back to 1
  • We need to perform post-mortems of breakages and learn from them as a community. It's OK that there are mistakes but we shouldn't make the same one twice.
  • Jim had the idea to experiment with 'telecommuting conferences' to find out whether the positive aspects of sprints can be achieved without the high burden of travelling by using audio/video/chat to discuss problems and ideas regularly.

telecommuting conferences --ktenney, Fri, 24 Sep 2010 14:43:24 -0400 reply

Openwonderland offers free software which seems to be suitable for this. http://openwonderland.org/

I ended up at a virtual sprint briefly / by mistake, those that knew what was going on seemed to be getting actual collaborative work done.

Lots of factors to consider in a comparison with actual video cameras.

Thanks, Kent