Difference between revisions of "WebComTODO"

From OSGeo
Jump to navigation Jump to search
m (→‎Medium Term: internal link)
(web site ssl certificate issue)
Line 10: Line 10:
 
# Setup feedback mechanism for web site.  I suppose this ought to be creating artifacts in the bug system, but a feedback email list might be more appropriate.  
 
# Setup feedback mechanism for web site.  I suppose this ought to be creating artifacts in the bug system, but a feedback email list might be more appropriate.  
 
# Recruit more members on discuss list.  What skills are most valuable?
 
# Recruit more members on discuss list.  What skills are most valuable?
 +
# Fix the SSL Certificate issue when entering the site (maybe don't use always https?)
  
 
=== Medium Term ===  
 
=== Medium Term ===  

Revision as of 15:00, 27 February 2006

List of tasks to be done by Web Committee. Eventually I imagine this should be handled by the bug (artifact?) tracker but I don't know how to use that properly yet.


Frank's Suggestions

Short Term

  1. Update the OSGEO Website Terms of Service on the web site.
  2. Setup mechanism for people to create accounts website user accounts on their own.
  3. Setup WebCOM mailing list, and get committee members on it!
  4. Setup feedback mechanism for web site. I suppose this ought to be creating artifacts in the bug system, but a feedback email list might be more appropriate.
  5. Recruit more members on discuss list. What skills are most valuable?
  6. Fix the SSL Certificate issue when entering the site (maybe don't use always https?)

Medium Term

  1. Setup WebCOM web page, with "mandate" and policies and procedures.
  2. Work on web site overall style.
  3. Ensure that WebCOM members can update all appropriate web pages (ie. osgeo.org, webcommittee.osgeo.org, board.osgeo.org, etc).
  4. Hold an OSGeo Logo Contest.
  5. Flesh out the web site pages. New, about, contact, etc.
  6. Setup wiki.
  7. Organize translation volunteers.

Wiki

  1. Figure out a wiki technology to incorporate. Mediawiki seems really nice. The Java folks seems really keen on Confluence.
  2. Do we need this hosted on a non-collabnet server since it isn't a core collabnet service?
  3. We need some mechanism(s) to ensure the folks realize material in the wiki is not authoritative. That it is essentially individuals working documents, not foundation policy.
  4. Make sure the wiki requires some sort of login or something so it is not easily spammed.