Difference between revisions of "IncCom Meeting7"
Jump to navigation
Jump to search
(some typos, links) |
|||
| Line 20: | Line 20: | ||
# documented release cycle | # documented release cycle | ||
# marketing requirements | # marketing requirements | ||
| − | * formal process for updating | + | * formal process for updating official OSGeo docs |
# There should only be a limited set of Formal documents - the rest can remain in the current wiki format. | # There should only be a limited set of Formal documents - the rest can remain in the current wiki format. | ||
# Formal documents should not editable (via a wiki or similar). This could mean exporting to PDF, HTML or maybe locking the wiki editors to one person. | # Formal documents should not editable (via a wiki or similar). This could mean exporting to PDF, HTML or maybe locking the wiki editors to one person. | ||
| − | # The document should be given a version number, release date and owner. The owner will probably be one of the OSGeo committees. For the | + | # The document should be given a version number, release date and owner. The owner will probably be one of the OSGeo committees. For the [[Project Status Template]], this would be the Incubator Committee. |
# People should be able to raise "issues" against the document (referencing the doc and version number). These issues could be captured in the document's wiki, or in a bug tracking system. I'd be inclined to track issues in a bug tracking system. | # People should be able to raise "issues" against the document (referencing the doc and version number). These issues could be captured in the document's wiki, or in a bug tracking system. I'd be inclined to track issues in a bug tracking system. | ||
# The workflow for a documentation issue would be as follows, though to minimise overhead, the committee would probably approve a number of issues at once. | # The workflow for a documentation issue would be as follows, though to minimise overhead, the committee would probably approve a number of issues at once. | ||
| Line 31: | Line 31: | ||
## Approved: Owner committee has voted and approved change | ## Approved: Owner committee has voted and approved change | ||
## Closed: Change has been incorpored in new version of document | ## Closed: Change has been incorpored in new version of document | ||
| − | * Discuss MapBuilder's readiness for graduation (possibly vote on graduating?) | + | * Discuss [[Community Mapbuilder Incubation Progress|MapBuilder]]'s readiness for graduation (possibly vote on graduating?) |
* Documentation license, advice? (something that is delaying geotools) | * Documentation license, advice? (something that is delaying geotools) | ||
| − | * Procedure to assign code to | + | * Procedure to assign code to OSGeo foundation |
| − | # completed | + | # completed provenance review |
| − | # completed product | + | # completed product review, see marketing requirements above |
| − | # request approval from the | + | # request approval from the OSGeo board, with included header, and sample release candidate showing complete product and documentation |
# based on positive response from board release is produced published | # based on positive response from board release is produced published | ||
Revision as of 11:36, 7 August 2006
Time
Proposed date: Monday August 7th.
Proposed time: 19:30 UTC - Fixed time around the world (3:30pm EST, 12:30am PST)
Proposed location: IRC channel #osgeo.
Agenda
- Approve minutes from IncCom Meeting6.
- Assign MapGuide mentor (Paul?)
- Discuss FDO as a subproject of MapGuide.
- Motion to update project status template with regard to committer responsibilities.
- Discuss items coming out of Sean's post.
- it is implied that all 8 original projects will graduate
- bug tracking
- social health (processes institutionalised - in practice for 6 months)
- user documentation
- documented release cycle
- marketing requirements
- formal process for updating official OSGeo docs
- There should only be a limited set of Formal documents - the rest can remain in the current wiki format.
- Formal documents should not editable (via a wiki or similar). This could mean exporting to PDF, HTML or maybe locking the wiki editors to one person.
- The document should be given a version number, release date and owner. The owner will probably be one of the OSGeo committees. For the Project Status Template, this would be the Incubator Committee.
- People should be able to raise "issues" against the document (referencing the doc and version number). These issues could be captured in the document's wiki, or in a bug tracking system. I'd be inclined to track issues in a bug tracking system.
- The workflow for a documentation issue would be as follows, though to minimise overhead, the committee would probably approve a number of issues at once.
- Open: Issue created by someone referencing document and version
- Open: Comments added to issue
- Fixed: Rough concensus has produced suggested replacement text
- Approved: Owner committee has voted and approved change
- Closed: Change has been incorpored in new version of document
- Discuss MapBuilder's readiness for graduation (possibly vote on graduating?)
- Documentation license, advice? (something that is delaying geotools)
- Procedure to assign code to OSGeo foundation
- completed provenance review
- completed product review, see marketing requirements above
- request approval from the OSGeo board, with included header, and sample release candidate showing complete product and documentation
- based on positive response from board release is produced published