Hi all, Cor Nouws wrote: > Hi Eike, Bernd, *, > > Eike Rathke wrote (14-11-2007 12:07) > >> On Wednesday, 2007-11-14 10:06:21 +0100, Bernd Eilers wrote: >> >>> What I consider bad on using this fallback is the problem that the >>> feature-info is often to technical to be used for the release notes, >>> eg. it´s often mentioning stuff like ChildWorkspaces where something >>> got integrated etc. which the end user doesn´t know about what this >>> is but well that may be only my impression. >> >> That's a matter of education then. Developers should get acquainted with >> the idea that feature announcements should be written such that they're >> end user compatible ;-) >> >> We could also agree on something like tagged sections, such as a >> [technical] >> blah here >> [/technical] >> would not be included in a compilation of feature announcements. Using >> square brackets instead of angle brackets would prevent confusion with >> HTML tags if the text is to be included in some HTML page like a wiki or >> such. The EIS form could actively support that by offering two >> textareas, one description for users, one technical. > > For general users and marketing, easy understandable wording is important. > But for people preparing the end-user-Wiki (for that purpose) more > technical info can be useful. > Also, it's not the job or competence of a developer to write end user > compatible, is it? Would be a pity if that took a lot of effort.
I completely agree with you. And we need to go to the complete description (issue, specs) to fully understand what the feature is about. Many times, comments on the issue help to understand the overall goal of the functionality where the specs helps to find it and how it works. So these informations are useful for us (and also for l10n purpose). > > Full information for those testing and writing the end-user-Wiki > (without any features missing) would be sufficient, IMO. and without errors. I don't know if it's the case now, but before I need to check on EIS to make sure the feature were integrated and at a user level (Smart Tags is an example so it still happens ;) just to make sure that we don't announce features that are not yet available and that the pointed issue is the good one. > > Unless of course, a situation can be achieved where the system and > procedures can expected to produce info that: > - always has all features; > - is well understandable for end users; > - directly exports to the feature announcements-page. > In that case, extra effort for the end-user-Wiki as it is now, would be > useless :-) +1 :) Kind regards Sophie --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
