h1. Kick-off discussion (April 3, 2008)
The memo at below with a title of "Draft Strategy Statements for GADC.next" was used at today's discussion. I tried to catch things discussed and agreed upon during the meeting in _italic_ at the memo.
Shinobu would like to have a presentation at G11nPAC within three weeks or so. This calls for the initial draft preso be ready by 4/17 (Thr). Weekly meeting will be necessary until the presentation. The preso will have about 5-6 slides plus some appendices as needed.
The following were implicitly agreed on the preso structure. (I added the first line to possibly give some background info and/or existing value proposition of the current GADC.)
- Monthly page hits for the last one or two years to GADC
- Direction
- Strategy & focus
- Actual structure proposed
- Justifications
- Appendices
Michael has an action item of providing the current inventory of the GADC.
Here is the memo used:
h4. Draft Strategy Statements for GADC.next
*1. Overview*
Considering we have rather significant amount of page hits and continuing inquiries to the current GADC, it is almost natural for us to think about on how to capitalize on such external and internal interests to our G11N portal of GADC.
*2. Focus & Strategy*
I think that if we can do the following four things:
- Official G11N portal
- Funnel/multiplexer
- Knowledge-base
- Online training
then we are in very good shape.
*2.1. Official G11N portal for Sun products:*
- Main focus for GADC should be on supporting our products:
-- In the future, possibly we may need a connection/link to services organization to be a part of service offerings.
-- Possibly we could extend our G11N consulting services to external; becoming a portal for external consultations.
*2.2. Be the "funnel" or "multiplexer" to other portals and forums:*
- Become the one-stop location where people can always rely on to be redirected as appropriate as humanly possible. Some examples:
-- System admins -> Big Admin or to itself
-- Application developers -> to itself or java.sun.com
-- Localizers -> to itself and other possible tools (glossary, translation editors, etc)
-- G11N system developers -> OpenSolaris.org, OOo, GNOME, ...
-- G11N documentation -> Doc/TechPub portal
-- End-users -> to itself
-- QC/test/QA engineers and users -> test environment portal(s)
_Technical difficulties related to the above were discussed for some time during the meeting._
*2.3. Be the G11N knowledge-base host:*
- Should contain info or links to relevant G11N knowledge/info.
- Initially focusing on Sun products and related offerings; extending to other companies' over a long period of time.
- Extremely well organized with multiple views and facets.
- Very good search return.
_We should first focus on building the contents vs. organization and search._
*2.4. Be the G11N online training host:*
- Host or point to relevant online trainings and materials.
-- Interactive, multimedia course materials.
-- Get-right-on-to-the-point materials that starts with questions like "How to make my program accept Asian characters?" and easy to understand step-by-step answers/procedures.
-- Sample codes, sample test scenarios, sample test data, virtual lab(? --- this is a wishful thinking)
- Should be able to issue some form of certificates that people can actually use in their professional careers?? <-- Perhaps with some relationship with SLS?
_It might be better to be included into the existing SLS' ceritification system._
*3. Resource required*
[TBC]
*4. Schedule for deployment*
[TBC]
END_OF_MEMO.
h3. The Venue
Right now the GADC is hosted on developers.sun.com. It has been proposed to move it to wikis.sun.com.
This may well be the right move, but it's worth attempting to document the pros and cons of each venue.
|| Feature || Developers || Wikis || Comments ||
| Open Editing | No | Yes | But content can be protected as necessary|
| Comment Addition | No | Yes | Can be controlled on a per-page or per-user basis |
| Change notification | No | Yes | |
| RSS feeds | No | Yes | Wikis provides an RSS feed builder |
| Structured Metadata | Yes | Not really | Wikis gives you 'tags', but not traditional metadata that can be leveraged by search engines outside of the wiki app. Can't tag content for language. |
| Search | | | Both provide search capability. Both searches can handle non ASCII queries. Developer search is better integrated into Sun's other web properties |
| IA | | | Both similar ... dependent on how user implements content |
| Form processing | Yes | No ? | developers can host scripts for form processing |
| API | No | Yes | Content can be programmatically changed in wikis through the API |
| Audience | | | Developers, obviously has a developer audience. Not entirely sure about wikis. |
| Labels | - | Yes | Wikis has a nice feature that automatically aggregates all content with particular labels |
There are likely lots more features that I haven't considered in this table.
Clearly wikis offers considerably more functionality than developers. However, we do have a very steady audience on developers, and any migration could result in losing some of them.
Any migration from developers to wikis, will require significant work to convert the HTML to wiki markup.
The memo at below with a title of "Draft Strategy Statements for GADC.next" was used at today's discussion. I tried to catch things discussed and agreed upon during the meeting in _italic_ at the memo.
Shinobu would like to have a presentation at G11nPAC within three weeks or so. This calls for the initial draft preso be ready by 4/17 (Thr). Weekly meeting will be necessary until the presentation. The preso will have about 5-6 slides plus some appendices as needed.
The following were implicitly agreed on the preso structure. (I added the first line to possibly give some background info and/or existing value proposition of the current GADC.)
- Monthly page hits for the last one or two years to GADC
- Direction
- Strategy & focus
- Actual structure proposed
- Justifications
- Appendices
Michael has an action item of providing the current inventory of the GADC.
Here is the memo used:
h4. Draft Strategy Statements for GADC.next
*1. Overview*
Considering we have rather significant amount of page hits and continuing inquiries to the current GADC, it is almost natural for us to think about on how to capitalize on such external and internal interests to our G11N portal of GADC.
*2. Focus & Strategy*
I think that if we can do the following four things:
- Official G11N portal
- Funnel/multiplexer
- Knowledge-base
- Online training
then we are in very good shape.
*2.1. Official G11N portal for Sun products:*
- Main focus for GADC should be on supporting our products:
-- In the future, possibly we may need a connection/link to services organization to be a part of service offerings.
-- Possibly we could extend our G11N consulting services to external; becoming a portal for external consultations.
*2.2. Be the "funnel" or "multiplexer" to other portals and forums:*
- Become the one-stop location where people can always rely on to be redirected as appropriate as humanly possible. Some examples:
-- System admins -> Big Admin or to itself
-- Application developers -> to itself or java.sun.com
-- Localizers -> to itself and other possible tools (glossary, translation editors, etc)
-- G11N system developers -> OpenSolaris.org, OOo, GNOME, ...
-- G11N documentation -> Doc/TechPub portal
-- End-users -> to itself
-- QC/test/QA engineers and users -> test environment portal(s)
_Technical difficulties related to the above were discussed for some time during the meeting._
*2.3. Be the G11N knowledge-base host:*
- Should contain info or links to relevant G11N knowledge/info.
- Initially focusing on Sun products and related offerings; extending to other companies' over a long period of time.
- Extremely well organized with multiple views and facets.
- Very good search return.
_We should first focus on building the contents vs. organization and search._
*2.4. Be the G11N online training host:*
- Host or point to relevant online trainings and materials.
-- Interactive, multimedia course materials.
-- Get-right-on-to-the-point materials that starts with questions like "How to make my program accept Asian characters?" and easy to understand step-by-step answers/procedures.
-- Sample codes, sample test scenarios, sample test data, virtual lab(? --- this is a wishful thinking)
- Should be able to issue some form of certificates that people can actually use in their professional careers?? <-- Perhaps with some relationship with SLS?
_It might be better to be included into the existing SLS' ceritification system._
*3. Resource required*
[TBC]
*4. Schedule for deployment*
[TBC]
END_OF_MEMO.
h3. The Venue
Right now the GADC is hosted on developers.sun.com. It has been proposed to move it to wikis.sun.com.
This may well be the right move, but it's worth attempting to document the pros and cons of each venue.
|| Feature || Developers || Wikis || Comments ||
| Open Editing | No | Yes | But content can be protected as necessary|
| Comment Addition | No | Yes | Can be controlled on a per-page or per-user basis |
| Change notification | No | Yes | |
| RSS feeds | No | Yes | Wikis provides an RSS feed builder |
| Structured Metadata | Yes | Not really | Wikis gives you 'tags', but not traditional metadata that can be leveraged by search engines outside of the wiki app. Can't tag content for language. |
| Search | | | Both provide search capability. Both searches can handle non ASCII queries. Developer search is better integrated into Sun's other web properties |
| IA | | | Both similar ... dependent on how user implements content |
| Form processing | Yes | No ? | developers can host scripts for form processing |
| API | No | Yes | Content can be programmatically changed in wikis through the API |
| Audience | | | Developers, obviously has a developer audience. Not entirely sure about wikis. |
| Labels | - | Yes | Wikis has a nice feature that automatically aggregates all content with particular labels |
There are likely lots more features that I haven't considered in this table.
Clearly wikis offers considerably more functionality than developers. However, we do have a very steady audience on developers, and any migration could result in losing some of them.
Any migration from developers to wikis, will require significant work to convert the HTML to wiki markup.