LSB conf call notes for 2009-07-01

Here's some clarification:

The issue is primarily that core documents and important information about the LSB are still on the old mediawiki system. Google picks these up and they get a lot of traffic. The problem with that is two fold:

1. These documents are out of date and don't appear to be being maintained by anyone. For instance, this http://www.linuxfoundation.org/en/LSB_Roadmap seems out of date to me. I would assume by this that there will be no LSB after 4.0 if this is the stated "roadmap". This document is easy found via a google search on LSB roadmap which is a pretty common search.

Also, if you put "LSB certification" into google you will get this page which to my eyes is not up to date to the document on certification that Jeff recently wrote: http://www.linuxfoundation.org/en/Certification


All of this certification information needs to be on LDN. As mentioned the trademark page is another example of this.

2. Besides the documents being out of date, the navigation of the mediawiki site is out of date and does not reflect current projects of the Linux Foundation. There are re-directs in place that take users to the new site, but obviously this is very confusing for end users who would then be jumped between sites with no clear way to navigate back. We are getting rid of the media wiki site for this reason as well as maintenance.

We need all the public facing documents from media wiki to be moved to LDN, so if people want to certify they go to that site and have everything they need. The old /en pages need to be deprecated so search engines only point people to one, easy to use site for certification, application checker testing, spec downloads, product directories, trademarks and so on.

There are many internal workgroup documents that are not of a big concern here as long the workgroup has worked with Brian to make sure the important documents are moved and deleted. As of now, this will not be done with an automated script, and honestly moving a bunch of pages from one site to the next will not solve the problem of having out of date or insufficient public documentation that is not easily navigable. The experts in this workgroup need to work with Brian to identify the right pages, update them and then create them/move them to LDN so anyone who wants to certify/test their app/ask a question/etc can easily find the answer.


If you guys cannot use the workgroup functionality of the new lf.org site, we can look into a private dev wiki for you, but again the main issue here is moving public-facing documents that need to be moved. I would like to understand why the LF.org LSB workgroup pages aren't usable for the workgroup. I see a note here about race conditions but that is not somethign that is a problem with the LF.org site. I know Drupal isn't as smooth as media wiki in some areas but other workgroups seem OK with it. Again, if it's not adequate we can create a wiki.linuxfoundation.org/lsb or something like that as a scratchpad site for collaboration.


Amanda

On Wed, Jul 1, 2009 at 9:14 AM, Jeff Licquia <jeff@licquia.org> wrote:

Attendees: Jeff Licquia, Russ Herrold, Stew Benedict, Brian Proffitt,

Ted Tso, Kay Tate, Robert Schweikert.



LDN.  Brian: sometime in the next month or two, we need to get the

current wiki content into LDN.  That should be the new home for that.

Two phases: identify and classify content regarding public-facing

content.  Three kinds of content: public-facing, administrivia (meeting

notes, etc.), and developer notes.  Second phase will be to move them

over to a wiki-like system on LDN.  Drupal will not be as flexible as

MediaWiki, but with a good workflow, shouldn't be too much more difficult.



Russ: can we stick with a mixed system?  Why get rid of MediaWiki?

CentOS is facing a similar issue.  Brian: don't have the resources to

maintain two different systems.  Ted: do we really need to move all

content?  Historical pages might not need to be migrated.  Brian: it was

put to me that everything would be moved.  Ted: reformatting and link

fixing is a really big job.  Drawbacks for Drupal (like race conditions)

make it less than ideal for internal content.  Brian: not sold entirely

on moving all content, but either will move or lose content.  Ted:

manual move?   Brian: no, there will be an automated script to do most

of the heavy lifting.



Russ: can't you use web access logs to identify current pages?  Brian:

yes, and Google Analytics.  Not the whole story; for example, few hits

to critical pages/parts of the site.  Ted: would recommend logs; Google

Analytics doesn't always catch everything.  Alan: massive project; we

should look at that list.  "Unpopular but important" is a problem;

fixing it might be a lot of work.  Ted: some of that will be

"scratchpad" pages that get a few hits per day, but still important.

Drupal is a terrible scratchpad.  Brian: agree 100%  Been told that we

can add wiki-like functionality to Drupal.  Had problems with it on the

corp site; not good.



Jeff: maybe the wiki gets separated from the corp site, but sticks

around as a "dev wiki".  Alan: that's my expectation.  Ted: problem is

that "lf.org/en" is the wiki.  If it moves off that, perhaps that makes

life easier.  Would that get us off the critical path?  Alan: time and

resources.  Ted: is it really that the wiki is in the critical path, as

opposed to maintenance?  Brian: yes.  Getting the corporate pieces out

and re-homing it will probably be sufficient.  Heavy lifting should be

done by us.  Jeff: dual-home the wiki, say under dev.lf.org/wiki?  Ted:

we also need to identify that content that needs to move to LDN.  Can be

done in parallel.  The trademark page, for example, is still on the wiki

and is out of date.  Jeff: do migration of pages and dual-homing?  Ted:

since David is on vacation, might start with migration.  Jeff: how do we

identify?  Brian: can get that list and email it.  Ted: can we identify

them automatically; any pages in Drupal that link into MediaWiki?

Brian: we can probably do that too.  David, at least, can do that.

Jeff: so, two tasks: David can dual-home the wiki, and the rest of us

identify articles that need to migrate.



Brian: reference library section coming, for articles to live once they

rotate off the front page.  Ted: can Drupal do this?  Brian: the issue

is for this to happen automatically; manual is easy to do.  Ted: this is

where wikis are good; easy to reorganize if we don't get the initial

hierarchy right.  Russ: in fairness, wikis can be too ad-hoc to find

things easily too.  Jeff: can we see a prototype?  Brian: yes.  Ted: or

just circulate a list of requirements.  May need to take this offline.