Revision as of 14:12, 12 July 2007

2007-07-05

10:00–11:30 CEST

Attendees

• Bettina Haberer
• Joachim Lingner
• Jürgen Schmidt
• Kai Sommerfeld
• Martin Damboldt
• Stefan Taxhet
• Thorsten Bosbach
• Nils Fuhrmann
• Stella Schulze
• Laurent Godard

Minute Taker: TBO next (BH, JSC, KSO, ST, MD, TBO)

Action Items

• How could an update feed be generated on the extensions.services.opennoffice.org site? (TBO, In progress)

-> Postponed to do it after finishing the change of the branding.

• Redesign the extensions.services.openoffice.org site (STS, In progress)

-> Stella will take a look onto the presentation page for an extension.

• Establish a new virtual host on the same server as our extensions repository to handle the updates of extensions (TBO, stalled)

-> No feedback so far from OSUOSL about this request. Not needed anymore - the important point was to be able to redirect, which can be done with http://updateext.services.openoffice.org/

• Extend Extension Manager to use default extension update URL contained in version.ini for update pings (JL, Open i77752)

-> Not done yet, still targeting 2.3 release. Due date middle of july.

• Provide extensions update URL that is to put into version.ini of 2.3 (TBO, done)

-> http://updateext.services.openoffice.org/ProductUpdateService/check.Update

• Provide document describing the benefits of OXT over Non-OXT as target for "Developer Resources" (JSC, open, due 2007-07-05)
• Prepare Mock-ups for Improved Site (STS, done)
• Prepare Notification of Extension Owners about Site (ST, Open)

-> Stefan needs notification about ten days ahead before the site is going 'public'

• Prepare Documentation for Users as target for "User Resources" (BH, Open)

-> BH expects to finish on 2007-07-06

• Start discussion about rating/review of extensions on mailinglist (Laurent, new)
• Prepare an example full feature download extension, to review the presentation of the extension (TBO, STS: new)

-> http://extensions.services.openoffice.org/project/testaddin00

Topics

• Laurent came up with: Translation of a) site UI and b) extension presentation text and c) the extension itself.
  • It was agreed to first get the general function of the site done.
  • Then start with a) by asking the native language groups to provide the needed strings.
  • For b) the way how it could be done with drupal needs some investigation.
  • c) is currently out of scope.

• Laurent raised the question about security: How can we make shure only 'good' extensions are shown?
  • a) Provide a link or button like 'Report abuse here', to be able to get a notification about bad behaving extensions.
  • b) The general quality can be seen by the ranking of an extension.
  • c) Establish a review by the community.
• These topics will get discussed at the OOo conference 2007 in Barcelona during the extension meeting and on the mailing list.

• Design voting
  • It was agreed on the 2. proposal with the search box from the 3. proposal.
  • The logo will get splitted, the text will not be a graphic.
  • The text changes to: Welcome to the home of OpenOffice.org extensions!

• It was started a discussion on how the extension will be presented on the page.
  • The design will get evaluated by Stella.

2007-07-12

10:00–11:30 CEST

Attendees

• Bettina Haberer
• Joachim Lingner
• Jürgen Schmidt
• Kai Sommerfeld
• Martin Damboldt
• Stefan Taxhet
• Thorsten Bosbach
• Nils Fuhrmann
• Stella Schulze
• Laurent Godard

Minute Taker: JL next (BH, JSC, KSO, ST, MD, TBO, NF, STS, JL)

Action Items

• How could an update feed be generated on the extensions.services.opennoffice.org site? (TBO, In progress)

-> Postponed to do it after finishing the change of the branding.

• Redesign the extensions.services.openoffice.org site (STS, In progress)

-> Stella will take a look onto the presentation page for an extension.

• Extend Extension Manager to use default extension update URL contained in version.ini for update pings (JL, done but CWS not yet integrated, issue i77752)
• Provide document describing the benefits of OXT over Non-OXT as target for "Developer Resources" (JSC, open, due 2007-07-05)
• Prepare Mock-ups for Improved Site (STS, done)
• Prepare Notification of Extension Owners about Site (ST, Open, due on Aug 1st)

-> Stefan needs notification about ten days ahead before the site is going 'public'

• Prepare Documentation for Users as target for "User Resources" (BH, Open)

-> BH expects to finish on 2007-07-06.

• Start discussion about rating/review of extensions on mailinglist (Laurent, done)
• Prepare an example full feature download extension, to review the presentation of the extension (TBO, STS: in progress)

-> http://extensions.services.openoffice.org/project/testaddin00

• Martin will find out about license conditions for using anti virus software on the extension website.
• Laurent will set up a private "abuse" mailing list

Topics

• Automatically scanning submitted extensions for viruses.

A submitted extension could be verified that it is not infected with a virus. Martin will try to find out about what scanner could be used (see action item).

• Automatic testing of submitted extensions

This does not seem to be feasible. We could use the virus scans + an "abuse" reporting mechanism as a means to filter out bad extensions.

• Discussing the new design for the "extensions box"

It was asked if one can find out who submitted the extension since the extensions box only shows the publisher. Answer: the administrator can find the information when editing the data belonging to the extensions.

• Position of the "Report abuse" button.

It could be put next to the ranking. Where exactly and what it will look like is up to Stella's decision.

• Reporting an abuse

A user needs to log in in order to make report. This should raise the hurdle for misusing this feature. The reporter will be presented a form where he/she can leave a description. Submitting the form will generate an e-mail to a "abuse" mailing list. Laurent will set this up (action item). This mailing list be NOT public. The reasoning for this is: It is easy to use the "abuse" feature in order to do harm. Once there is a public e-mail it may be mirrored and indexed and cached by search engines. Then unsuspecting users may use them to look for information regarding a particular extension and come across the "abuse" mail, although at that time it may have turned out unjustified. But then the harm is done - the user may change his/her mind about that product.

• Evaluate the abuse mails

We need to find volunteers who take care of evaluation the mails. Laurent will try to find people. They will be able to subscribe the "abuse" mailing list.

• Automatically disabling the download of an extension when a abuse has been reported

This will not happen, since submitting unjustified abuse mails would lead to repeated disabling of the download. For example, every few days an abuse is reported... Also showing a message indicating that the extension is currently being investigated would probably raise (unjustified) suspicion on part of the users.

• The design should be implemented by Thorsten by next week.

• Localization of the web site

We would need volunteers do this (translation and finding out how this could be done technically). Otherwise we will focus on getting the English version running.