Information Sharing/Meetings

From Apache OpenOffice Wiki
< Information Sharing
Revision as of 13:20, 6 September 2007 by Mmp (Talk | contribs)

Jump to: navigation, search

6-Sep-2007

1 pm - 2 pm

Attending: Martin, Matthias, Frank

Agenda

Minutes by Matthias

Frank (alas the http://documentation.openoffice.org project) distinguishes between 3 groups.

Users
- users of OOo
- developers who want to develop extensions or use OOo's API
- admins, who want to know how to install and configure OOo
Contributers
People who like to write and improve the documentation for the user group
Core Developers
People who like to improve the source code of OOo by adding new features and fixing bugs.

The scope of the documentation project is users and contributers, while we (Information Sharing) tackle the information demand for core developers.

FPE: What's needed is a manager for the core development documentation. Someone who is responsible for

  1. access/portal to the documentation
  2. completeness/comprehensiveness
  3. up to date of information
  4. ...

New information needs to be communicated to the core development documentation manager, who in turn can update the portal. She has to respond to the requirements of her users (core developers) and structure the information on her pages.

MH: We tried this approach with http://development.openoffice.org. which failed due to insufficient developer's focus of the page maintainer.

FPE: Take ooo-wiki as an example. It grows in a self-organized way that leads to a mess -- or it can have more structured areas with well-defined rules. A wiki name space can define such areas with the advantage to even search with Google in this name space on the wiki exclusively.

MMP: Categories are also very "free-style". Enhanced visibility for categories can help to motivate people to consolidate categories.

FPE: For all ooo projects introduce a category on the wiki. In fact, create 2 categories for each development project: one for public core developer documentation and the other as playground for the project.

MMP: and add links for the project.ooo.org pages to the wiki and vice versa.

FPE: says good bye. see u at OOoCon to talk about the state&fate of the ooo-wiki

MH: Let's take (for a moment) the perspective to create a book with documentation for core developers. Use a space on the wiki to collect the chapters according to a reasonable outline (how to get the code, how to built, software architecture of OOo, how to contribute, etc.). Many "pages" are already there -- just in a very scattered way and with different level of editorial style.

Once the wiki version is complete we can transfer it to OOo and create a real book - if we want (MediaWiki_Extension_Use_Cases#Creating_WikiReader).

Martin will create a simple outline for such a book project.

9-Aug-2007

Attending: Stefan, Martin, Matthias

1-Aug-2007

Attending: Stefan, Martin, Matthias

Minutes by Matthias

so-doc analysis

Martin prepared an analysis of all files of so-doc by age/type/team

The vast majority of files is stone-age old. It also seems that we use so-doc more like a team server rather than a document server (whatever the difference is).

How can we find the nuggets, alas, the valid information that should better be hosted somewhere on ooo? The age is just an indicator. It is no sufficient heuristic to decide on the fate of the files.

defects

defect category

We identified a fifth defect category: redundant information (between ooo.org and ooo-wiki)

Example
Someone hosts information on his ooo project site and on the ooo-wiki because the wiki does not offer the same left navbar as the ooo project sites do.

The five defect categories are:

  1. total absence of necessary information
  2. outdated information
  3. up-to-date but not open accessible information
  4. redundant information
  5. ( outdated and not open accessible information )

cf. Information Sharing Findings#Defect Categories

How to record defects (->measure of success)

1) IssueTracker is an option.

Information defects (according to the 5 defect categories) are submitted to IssueTracker.
The OOo Team Leads will be the default owner for such issues.
Pros: official, trackable, manageable

Stefan will present the idea in Michael's staff meeting.

2) assign a category to pages that need attention

Examples
for so-wiki: Template:MoveToOOo
for ooo-wiki: http://wiki.services.openoffice.org/wiki/Category:Candidates_for_speedy_deletion

MediaWiki extensions

Are there any extensions to MediaWiki which could help to do a better job?

AI for all
Matthias: how do the flags work on Wikipedia? -- ("This article needs your attention")
Martin: web tracking for MediaWiki, generate automatic site structure for MediaWiki sites?
Stefan: utilize Omniture Sitecatalyst to identify non frequented pages

Search

Unified Search for all ooo

Goal is to eliminate redundancies in favor to reduce search match doublets

Martin suggests to use Google over custom search engines for each oo site.

Search Engine Optimization (SEO)

Which search terms in Google lead to what pages on ooo? What search terms are used most often? We can have a look into SEO.

  • PageRank for our entry pages
  • use of keywords
  • proper use of HTML (also goot for accessibility)

Omniture Sitecatalyst to identify non frequented pages (consolidation)

Omniture can track the frequency of page visits for ooo. This data should be used to inform the project leads and to reveal insights on how to improve the project sites and to identify opportunities to combine distributed information.

ooo sitemap

Matthias has started to create a Information Architecture (IA) -oriented site map:

Initial findings

  • the header is different for home and project pages: the search function is top right, respectively integrated into the leftnav
  • the home page has no user account feature
  • the left navbar is optional, ie. some projects have removed this area
    • esp. Support has no left navbar, which offers Search, Sitemap, FAQ, Get Help?
  • logout leads to the login/register page. By doing this it changes the context entirely.
  • <ironic> do not visit the support page if you need support </ironic> It is a textual mess.

27-Jul-2007 kick-off

Attending: Stefan, Martin, Matthias

Minutes by Stefan

What leads to this project

  • problems occurred with new contributors (CH2000) who didn't find the info they needed, asking the developers and got a pointer to outdated info, asking about outdated info - the developer agrees - end of story

Michael Bemmer was involved in this incident and researched himself a bit in our information infrastructure. Doing this he got aware of the following facts: Our informational infrastructure is way too complex to be able to acquire helpful information easily. Many documents and sites are outdated, some not accessible to the whole community because posted on Sun internal media, or simply not existent.

Michael Bemmer champions this project and expect a list of "where to post what" recommendations as one of the outcomes of this project. He further expects the evaluation of internal information infrastructure (e.g.so-doc) wrt. outdated,"old", information pieces and wrt. the question if we could probably get rid of some medias in favor of less ambiguity

Why the SMEs (MH,MMP)

MH as the technical OOo guy and generalist for all kind of issues around community related issues, and MMP as highly skilled communication and UX "scientist" seem to be the perfect team for the job.

Both agreed on the charter so far, but all the three team members are aware of the fact that minor adaption to the charter may still be necessary. The team also agreed on the schedule of a weekly meeting, 12 times from now on which means immediate action.

The team talked about the following further topics:

  • necessity of a rule of separation between information and communication, which I currently break with this mail :))
  • Ownership
    • project page maintenance
    • doorman to guide new developers
    • active acquisition
    • address website problems
  • information transfer internal -> external
  • information restructure (site)
  • presentation about communication and the responsibility of the sender

Further things I would like to mention/discuss with the Team:

As far as I see we got 4 classes of defects

  1. total absence of necessary information
  2. outdated information
  3. up-to-date but not open accessible information
  4. ( outdated and not open accessible information )

As we are not doing a Sigma Project we should start to proceed the "just-do-it" kinda things What are these? Actually as soon as you discover one of the former categorized defects take care that it'll be addressed and log it.

example
When you hit an outdated page, record it in a list and take immediate action like contact the owner to fix it.


We were all not too happy with the goal statement what about this here?

Possible adjusted goal statement:

Improve the ability of community participants to access relevant information

Documents

  1. Information Sharing by Stefan
  2. OOo Website User Groups by Matthias
Personal tools