Joe Smith wrote: > Mathias Bauer wrote: >> Joe Smith wrote: >> >>> I've started to see these messages on the features announce list (via >>> Gmane). This seems like a good thing, but I have some questions: >>> >>> 1) Is there any mechanism for feedback on these features? >>> >>> None seem to have any issue number; are they supposed to be tracked >>> through the CWS name? If so, is there a feedback channel there? >> >> I think they should have an issue number - in case there is a single >> issue for that feature. Besides that they can indeed by tracked through >> the CWS name in EIS. > > Most have a CWS name, but in this case (a "community patch") there is > not even that.
Seems that this was done in a hurry. ;-) >> As every work UX work needs a focus. IMHO posting new features to a >> "discuss" list at random will not produce useful results. Perhaps it >> will make things even worse when the discussions (as often) won't come >> to an end or end without a concrete result. > > I agree: a random discussion is not the way to do UX design, but it is > part of the way. The iTeam can easily make a final decision and move on > at any time, if there is no consensus. Doing every feature development this way would bring development nearly to halt. I don't want to start each feature development with a broad public discussion, this won't work and will surely demotivate the developers. I agree that more feedback loops at specification and development time are desirable and I'm sure that qualified feedback is something that every developer likes to get. Incorporating more community UX feedback shouldn't be a fundamental problem for features developed in Hamburg, it's "just" a matter of tooling, effort etc. I see problems for features not provided by Sun's developers as a considerable and verbose part of the non-Sun developers is not very fond of UX in general and community UX involvement as a project goal in particular. More or less verbally I was told in a meeting that "the developers should be in charge". While I like to see developers driving the project I know where we have our limits. And I like to broaden our community by getting non-developers involved and contribute to our project with their abilities and knowledge. My own experience with community input for features is very positive. So much for "internal" vs. "external". > Yes, but it is precisely when the developers think that no outside input > is needed that the outside input is most needed ;-) You seem to overlook that an iTeam is not consisting of developers only, there's always a UX member involved. We even sometimes exaggerated a bit in the past, leaving all UI decisions to the UX members what often resulted in the feature development being stuck. This was a pity especially for patches from the community where we (rightly) got some very negative comments for not putting them forward. So we learned that sometimes a decision *made* by a developer is better than a decision *not made* by a UX engineer. ;-) > Tracking a feature through EIS is not good: it's very difficult and > there is no place for direct feedback. Not every CWS links back to any > issue; many link to several issues. I think your suggestion to allow for more and earlier feedback is valid and good. But getting involved should be a duty of those wanting to get involved, there shouldn't be a duty for iTeams to wait for input upfront. We tried to establish that by providing specifications early (again something that a part of the non-Hamburg developers does't like, a very prominent one of them even made a fun of it in his blog) but perhaps indeed the time when specs are published maybe quite late at times. Meanwhile we have started to publish ongoing development for larger features in the wiki so that input can be collected even before the spec is finished. Maybe we need a channel where such public development can be announced. An existing channel is our GullFOSS blog where Dieter Loeschky posts the ongoing work of all Hamburg teams once per weak. Perhaps we can add feedback links to that post. > There should be some link on the feature announcement, either to an > issue id, or to a mailing address ([EMAIL PROTECTED] is not > useful to outsiders!) or mailing list where comments can be made that > will definitely be seen by the iTeam. I expect most will get no > comments, but some will and some will be useful. Seconded. That should be easy to add. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
