On 04/26/2018 07:12 AM, Martin Srebotnjak wrote: >>> I'm only sad that we are not part of the discussion when we are highly >>> concerned. >> That probably has as much to do with where and when the discussions are >> held, as anything else. > you miss the point. Changing help (documentation project) and UI (UX project) > is not a self-enclosed thing.
One of the vices of agile development is that documentation is considered to be, at best, unnecessary. This applies for both developer documentation, and user documentation. Whilst the theory is that Agile Development has the following for End User Documentation Creation: * using a topic-oriented approach such as the Darwin Information Typing Architecture (DITA) or Information MappingTM * leveraging user stories to produce task-oriented documentation * applying minimalist principles * participating as an active team member the reality is that the usual Agile Development creed on end user documentation is _They Ain't Gonna Read It So Why Bother Writing It_. >This is one of the biggest open source projects and changes in code (and UI >and documentation) affect not only many community members participating in the >project on different tasks, but millions of users. The other part of the equation, is that there were/are features and capabilities in LibO that virtually nobody other than the original developer knows exist. Features that never made their way into any user-documentation, and only got one line in a developer synopsis. By way of example, which version of Logo is embedded within LibO? Only slightly more esoteric is which version of R does LibO have hooks for? (Who needs VBA when you've got R?) Now wondering if the Flight Simulator game was removed from LibO. > So we do need to copy or thoroughly adapt some of the "corporate" workflow > magic and make this process a road to success, not to chaos. Sun practiced waterfall development, in which specifications for everything were written out in advance. TDF practices agile development, in which nothing is specified until after delivery. The adoption of these models reflect what was considered to be "best practices" when the organization started developing the program. There are advantages and disadvantages to each of these models. >but there must be a workflow where such changes, when already thought through >by its native team, The thinking through, as such, happens during/after construction, not before construction. This is why the _only_ way that l10n teams can get a hint of what will happen, is to have a designated l10n team member, whose sole function is to sit in on each and every call, and follow both the Bugzilla, and Commits list, and the use-case and user-story storyboards for each proposed function, capability, etc. I realize that that is literally a full time job. > with l10n teams (who are not just localizers, translators, but in most cases > promoters of LO in their countries/languages/cultures and can offer a lot of > advice what might not be good for their language/cultural environment/law > requirements) - before they get introduced. So we need such a > forum/discussion point in development process. +1 > I often remember the OOo days where every upcoming bigger feature had a > webpage (a kind of a wiki page in the Sun web subworld) made by the > developers, That happened for both minor and major features. It is a side effect of the waterfall model of software development. If you roam around on the openoffice.org website, you can still find some/most of those web pages. >but all this iterative changing (that does lead to better and better results, >no doubt about it) in the end hits the l10n teams and makes their members feel >like Sisyphus. Sisyphus was lucky. He knew his fate. jonathon -- To unsubscribe e-mail to: documentation+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/documentation/ All messages sent to this list will be publicly archived and cannot be deleted
