On Mon, Aug 3, 2009 at 2:01 PM, Christoph Derndorfer<christoph.derndor...@gmail.com> wrote: > Quite frankly speaking I don't understand why the deployment related > conversations and feedback should be kept on IAEP when most of it > (especially at early stages of deployments and school projects, which is > were most small and large efforts are at the moment) will be of a relatively > technical > nature.
For the same reasons that splitting roles and responsibilities between Sugar Labs, Fedora, and OLPC has created some effective abstraction barriers. These barriers have cleaned up Sugar deployments quite a bit. In order to 'scale' up support we need a set of process and conventions for communicating between deployments and develops. > As an example let me mention the Austrian pilot where during my visits I'm normally > dealing with issues such as laptops not shutting down, activities being > deleted and collaboration not working as expected. The teachers there have a > fairly good idea of what they would want to use the laptops for if they or > the children didn't hit technical roadblocks that slow the classroom usage > down ever so often. All true. Taking this argument a step further in context of Sugar Labs; The underling challenge is not that deployments have technical problems, the challenge is creating methods for communicating these problems as usable information to develops. > It's only once we moved a bit behind those early > technical hickups that the discussions about the "good stuff" (education and > whatnot) will start to take place. Again true. Have you seen the draft project roadmap I sent to iaep I sent a few weeks ago? > Having said that I personally believe that the core consideration in such a > feedback process should be to have someone dedicate him- or herself to it. > As Greg Smith showed so well at OLPC a single person at an organization can > make all the difference when it comes to communication between deployment > and developer communities. Again true: Taking this argument a step further in context of Sugar Labs; First, how to we attract and engage a person with Greg's skills and knowledge? Second, how do we scale that person? Open source development _depends_ on people scratching their own itches. If a deployment wants a new feature or bug fixed it is in their best interest to help make that happen. Thus deployments _must_ become participants in Sugar Labs rather than consumers if they want their itches scratched. > At the same time deployments, regardless how large or small, should be > encouraged to offer at least a single (and reliable!) point of contact for > feedback collection. I would turn this on it's head and say, "For deployment support to scale, at least one member of a deployment should become an activate participant in Sugar Labs." > I really liked the list at > http://wiki.sugarlabs.org/go/Deployment_Team/Places that Tomeu started back > in February, however I just realized that (unless I missed something) the > people listed on that page have never been contacted in a structured manner > to give feedback. > So, to end this with an actionable item I would suggest that we start > flashing out a process and preferably an actual questionnaire of some kind > to be sent to people in deployments listed on the page mentioned above or > who we know personally (and subsequently encourage to sign up to the page > above;-) by the time brainstorming for 0.88 starts. With the 6-month release > cycle we have the opportunity to organize structured and timely feedback > flows twice a year. Again, this depends on 'having a we' without consideration for who that 'we' is that is expected to do the work. If a deployment want support of new feature they must become part of that 'we.' > At the same time we should make it as easy as possible for people to leave > their feedback, and when I say "as easy as possible" I'm not thinking of a > mailing-list, Trac or some wiki-template. Instead of scaring people away > with lots of tech-talk (like we do > on http://wiki.sugarlabs.org/go/Submit_Bugs/Problems at the moment) simply > put feedb...@sugarlabs.org in <h1> on key locations of the wiki and Web > site. You have taken your argument all the way around and reached the same conclusion as I did:) Developer use tech-talk. Deployers (for the most part) don't. The challenge is creating processes (bridges) which meet the needs of two important constituencies, deployers and developers. david > Anyway, it's getting late, time to grab some sleep... > Christoph > On Mon, Aug 3, 2009 at 11:55 PM, David Farning <dfarn...@sugarlabs.org> > wrote: >> >> One of the challenges over the next couple of months will be figuring >> out how to turn 'feedback' from deployments into useful 'information' >> which the bug squad and deployment team can use. >> >> As a first step, I would like to suggest that we keep deployment >> related threads on i...@sl.o. After all, deployments are the >> education part of the it's an education project. There will be a >> number of benefits to this: >> >> 1. Developers 'like' to work from bug trackers. Our bug tracker is >> at dev.sugarlabs.org . An example of a good bug report is at >> http://dev.sugarlabs.org/ticket/1100 . In this report Gary does a >> good job of clearly describing the problem. It is very common for bug >> reports to turn into conversation very similar to mailing list >> conversations as the bug reporter and bug fixer narrow in on the exact >> cause of the bug. There is some very useful metadata at the top >> report describing exactly which version and component you can find the >> bug. Finally, there is a the Ownedby field. If a bug is identified >> on a mailing list it is likely to be forgotten within minutes. Once a >> bug is entered into the tracker, someone owns the bug until they >> assign it to someone else. >> >> 2. Developers like to work from feature requests. Sugar stores >> feature requests on the wiki at >> http://wiki.sugarlabs.org/go/Features/Back_Up_and_Restore . A good >> example of a feature request is >> athttp://wiki.sugarlabs.org/go/Features/Back_Up_and_Restore . The >> format of the feature request make it easy for developer to figure out >> how a new feature fits into the exist code base and how to prioritize >> the feature. >> >> These two process are not just 'make work.' Most non-teachers, have >> very little grasp of the processes teacher use to keep a class room of >> squirmy kids focused on a learning objective. It is just going to >> take awhile until we learn to understand deployers need and >> specialized vocabulary. >> >> 3. By keeping the deployment discussion on iaep, we can work together >> to figure out how turn feedback into usable information for developers >> before turning it into bug reports or feature requests. >> >> 4. We can create a culture in which deployers and developers equally >> respected members of the sugar community. >> >> 5. By clearly splitting up the roles and responsibilities between >> developer and deployers we start to lay the foundation for reviving >> the deployment team. >> >> david >> _______________________________________________ >> Sugar-devel mailing list >> sugar-de...@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > > > -- > Christoph Derndorfer > co-editor, olpcnews > url: www.olpcnews.com > e-mail: christ...@olpcnews.com > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep