Hi Andre, all, On Sun, 10 Jul 2011 11:57:34 +0200 André Schnabel <andre.schna...@gmx.net> wrote:
> Am 09.07.2011 19:39, schrieb Kohei Yoshida: > > Regarding this bug > > > > https://bugs.freedesktop.org/show_bug.cgi?id=39068 > > > > Rainer started the specification process for this. > > I'd rather say he started to collect information in a structured way > to help all the people involved in a new feature implementation. And > to make more people aware that their help is needed. Which is a good and important thing because it helps to keep focus and consistency and lessens the risk of duplicate work. However there are a few things to keep in mind when writing these: - Keeping track of related bugs is a very good thing. It might be even better to create a meta bug for the spec that is blocked by all the subtasks (instead of manually tracking them on a wiki page which will be outdated and is errorprone). Bugzilla is a powerful tool, use it! - Bugs should always be selfconsistent work items. A bug should always contain all the information needed to fix the issue and not more. Esp. it should not even be required to read a spec to understand and fix single issue for it. - It is good to have 'contacts' on the spec. But nobody should show up there without being asked first (which I assume happened here), as it will imply responsibility and workload. In general, I think it is not bad to have specifications covering a wider set of bugs to make sure things develop in a consistent fashion(*), as long as they do not keep coders from coding. The tricky scenario is: When a volunteer coder sees a bug, wants to fix it, but the spec has not been finished yet. In such situations IMHO we must allow for a well-its-better-than-it-was-before-fix even if there is no full spec yet. This is simply because the volunteer is willing to contribute _now_ and not later. He might not be willing to adjust his fix according to the spec later? True, but if you prevent him to do an ad-hoc fix now, chances of further contributions from the volunteer are even less. Of course, sometimes someones well-its-better-than-it-was-before-fix is a sucks-worse-in-a-different-way-fix for somebody else. Personally, I tend to be more conservative in those cases (i.e. keeping the old behavior) because of the expected technical experience of our target endusers. But those need to be discussed on a case-by-case basis anyway. My 2cents. Best, Bjoern (*) Those would also help a lot in the creation of release notes I guess, which is still a bit frantical right now. -- https://launchpad.net/~bjoern-michaelsen _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
