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. 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. 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.<div> <br></div><div>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.</div> <div><br></div><div>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 really liked the list at <a href="http://wiki.sugarlabs.org/go/Deployment_Team/Places">http://wiki.sugarlabs.org/go/Deployment_Team/Places</a> 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.</div> <div><br></div><div>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.<br> <br></div><div>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 <a href="http://wiki.sugarlabs.org/go/Submit_Bugs/Problems">http://wiki.sugarlabs.org/go/Submit_Bugs/Problems</a> at the moment) simply put <a href="mailto:feedback@sugarlabs.org">feedback@sugarlabs.org</a> in <h1> on key locations of the wiki and Web site.</div> <div><br></div><div>Anyway, it's getting late, time to grab some sleep...</div><div><br></div><div>Christoph</div><div><br><div class="gmail_quote">On Mon, Aug 3, 2009 at 11:55 PM, David Farning <span dir="ltr"><<a href="mailto:dfarning@sugarlabs.org">dfarning@sugarlabs.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">One of the challenges over the next couple of months will be figuring<br> out how to turn 'feedback' from deployments into useful 'information'<br> which the bug squad and deployment team can use.<br> <br> As a first step, I would like to suggest that we keep deployment<br> related threads on iaep@sl.o. After all, deployments are the<br> education part of the it's an education project. There will be a<br> number of benefits to this:<br> <br> 1. Developers 'like' to work from bug trackers. Our bug tracker is<br> at <a href="http://dev.sugarlabs.org" target="_blank">dev.sugarlabs.org</a> . An example of a good bug report is at<br> <a href="http://dev.sugarlabs.org/ticket/1100" target="_blank">http://dev.sugarlabs.org/ticket/1100</a> . In this report Gary does a<br> good job of clearly describing the problem. It is very common for bug<br> reports to turn into conversation very similar to mailing list<br> conversations as the bug reporter and bug fixer narrow in on the exact<br> cause of the bug. There is some very useful metadata at the top<br> report describing exactly which version and component you can find the<br> bug. Finally, there is a the Ownedby field. If a bug is identified<br> on a mailing list it is likely to be forgotten within minutes. Once a<br> bug is entered into the tracker, someone owns the bug until they<br> assign it to someone else.<br> <br> 2. Developers like to work from feature requests. Sugar stores<br> feature requests on the wiki at<br> <a href="http://wiki.sugarlabs.org/go/Features/Back_Up_and_Restore" target="_blank">http://wiki.sugarlabs.org/go/Features/Back_Up_and_Restore</a> . A good<br> example of a feature request is<br> athttp://<a href="http://wiki.sugarlabs.org/go/Features/Back_Up_and_Restore" target="_blank">wiki.sugarlabs.org/go/Features/Back_Up_and_Restore</a> . The<br> format of the feature request make it easy for developer to figure out<br> how a new feature fits into the exist code base and how to prioritize<br> the feature.<br> <br> These two process are not just 'make work.' Most non-teachers, have<br> very little grasp of the processes teacher use to keep a class room of<br> squirmy kids focused on a learning objective. It is just going to<br> take awhile until we learn to understand deployers need and<br> specialized vocabulary.<br> <br> 3. By keeping the deployment discussion on iaep, we can work together<br> to figure out how turn feedback into usable information for developers<br> before turning it into bug reports or feature requests.<br> <br> 4. We can create a culture in which deployers and developers equally<br> respected members of the sugar community.<br> <br> 5. By clearly splitting up the roles and responsibilities between<br> developer and deployers we start to lay the foundation for reviving<br> the deployment team.<br> <br> david<br> _______________________________________________<br> Sugar-devel mailing list<br> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br> </blockquote></div><br><br clear="all"><br>-- <br>Christoph Derndorfer<br>co-editor, olpcnews<br>url: <a href="http://www.olpcnews.com">www.olpcnews.com</a><br>e-mail: <a href="mailto:christoph@olpcnews.com">christoph@olpcnews.com</a><br> </div>