I'd ready to take the consultants directory forward. The main
remaining tasks are:
1) Confirm that the current data schema is adequate.
2) Write up submissions requirements for consultants, to get their
listings added
3) Get initial listings added
These three are closely-related and it will probably require an
iterative approach to get these right. So it would be of great help
to me if a few (3-4) consultants on the ooo-dev list would be willing
to work with me to get their listings added now. This may require
some back-and-forth as we adjust the schema or uncover additional
policy nuances. But better to find this out early.
If you are interested, please sent me an XML fragment like this, with
your information in it:
<consultant>
<name>Joe Bloggs, LLC</name>
<country>DE</country>
<country>CH</country>
<country>AT</country>
<practice>Deployment</practice>
<practice>Migration</practice>
<description>Joe Bloggs, LLC provides custom deployment and
migration servives for small and medium business moving to OpenOffice.
We work with the client from initial
evaluation and piloting, through deployment and beyond.
References and whitepaper are available on our website.</description>
<website>http://www/jbloggsllc.com/openoffice.html</website>
<email>j...@jbloggsllc.com</email>
<phone>123-456-7890</phone>
</consultant>
name == name of your entity, could be your personal name or name of your company
country == one or more ISO country codes that you do business in. If
you do business everywhere you can say "Global"
practice == one or more areas of practice. I'd like to use this for
categorization, so it will be a fixed list of options. Currently I'm
proposing: Deployment, Migration, Extensions, Training,
Customization. Other. Are there any other areas we should mention
specifically?
description == plain text, no HTML, description, limit of 300
characters. It should be factual, not an advertisement.
website == URL of your website
email (optional) == contact email address
phone number (optional) == contact phone number
Are these fields reasonable? Any others we should have?
And again, getting some real, specific, non-fake data added will help
validate the design.
Thanks,
-Rob
