transparantezaken's status on Wednesday, 17-Jun-09 07:02:18 UTC - Identi.ca

transparantezaken's status on Wednesday, 17-Jun-09 07:02:18 UTC - Identi.ca — Wed, 17 Jun 2009 10:02:33 GMT

PingBack from http://identi.ca/notice/5411796

re: ODF Plugfest, The Hague

Mitch 74 — Mon, 22 Jun 2009 11:40:39 GMT

Wow! That looked like a busy 2-day hack-fest!

Will we get more data on the scenarios described here: http://plugtest.opendocsociety.org/doku.php ?

Embedded spreadsheets in text and in presentations are left blank (no implementation bugs listed)... Is it because of radically different approach to the problem from suite to suite (one embeds a complete ODF document, another simply copies over a 'table' element, following draft ODF 1.2...), that made testing irrelevant?

About my former comment, on your former blog post: yes, I understand you value documentation in a development process; indeed, documentation is extremely important, especially if looking for interoperability (in some cases, access to source code would help); taking part and actively pushing these plug-fests forward is GOOD.

About a 'filter', let's change the word to parser/loader, would there be possibility, in the future, to have access to alpha, beta, nightlies etc. of the ODF parser/loader for Office 2007 SP2 so that someone, on the other side of the world, and who can't speak English, can try it?

If I take other suites' situation, several have localized versions, and use localized mailing lists for user comments and support (some also have localized developers mailing lists for major languages); that allows a Vietnamese user to report a bug in, say, glyph alignment, discussion on the bug, how reproducible it is, BEFORE it is translated into a main developers' bug report (by then, it has been well documented, and sometimes faulty code detected).

For example, I recently reported a valid bug in an MS product, in my native language (which is one of the 10 most spoken languages in the world); the following answer and bug report (apart from my submission) were translated in English. I could recover and continue until the bug report was closed, but it all took place in English.

Here, you'd have already lost most of the world's population that doesn't speak English: how can you discuss and document a bug, something that requires precision and understanding, if one side doesn't speak the language of the other? Localized support would be nice, at first - even if informal (mailing lists).

When you don't have code or can't compile, you can at least make use of daily builds, and send said build to a bug reporter to test if the bug was solved; in many cases, if you simply give access to daily builds publicly, you can allow users that submitted a bug to maintain and close their bug themselves - offloading your own staff's workload, and reducing inertia (the delay between a bug appearing/changing and developers being notified).

"non-registered non-paying customers" could be: users of previous MS Office versions, wanting to test future builds without wanting to go through the hurdle of registering to Connect beta programs (many are invite-only, so they are not even sure they CAN register) or of paying for an MSDN subscription. So yes, in opposition with paying, registered customers :p

Why would they want to do that? To test a future product's advancement, and see how it fits against their requirements. If they think it matches mostly well, but notice an annoying bug, THEN they may want to register and report said bug - not before.

re: ODF Plugfest, The Hague

Bart Hanssens — Thu, 25 Jun 2009 12:29:38 GMT

Mitch: the participants agreed to keep the plugtest wiki alive, so make sure you'll visit it on a regular basis ;-)

re: ODF Plugfest, The Hague

Mitch 74 — Thu, 25 Jun 2009 12:59:22 GMT

@Bart: I'll certainly keep an eye on the wiki. Note that a complete description of an interoperability problem is a very good thing, very open trial versions of solutions to said problem is an even better thing (thus my lengthy comment above ^^)