[Incubator] Re: [VisCom] Re: [Incubator] Branding/Sales information required in Graduation Template

[Cameron Shorter]

Jody has a good point about determining why we ask for reports. It lines 
up nicely with the CMMI Processes for Measurement and Analysis:

http://www.sei.cmu.edu/publications/documents/02.reports/02tr012.html

"The Measurement and Analysis process area involves the following: 
[PA154.N101]
•	Specifying the objectives of measurement and analysis such that they 
are aligned with identified information needs and objectives
•	Specifying the measures, data collection and storage mechanisms, 
analysis techniques, and reporting and feedback mechanisms
•	Implementing the collection, storage, analysis, and reporting of the data
•	Providing objective results that can be used in making informed 
decisions, and taking appropriate corrective actions

..."


To determine the OSGeo Business needs we should look at our mission 
statement (from the https://www.osgeo.org/ ). Key words in capitals.

"The Open Source Geospatial Foundation has been created to support and 
BUILD the HIGHEST-QUALITY, OPEN SOURCE, GEOSPATIAL software. The 
foundation's goal is to ENCOURAGE THE USE and COLLABORATIVE DEVELOPMENT 
  of COMMUNITY-led projects."

So lets see if we can find some indicators (measures) to monitor each of 
our goals.

HIGHEST-QUALITY:
Is the product as good as others on the market?
Is the prodcut reliable.
Is the product stable.
Potential measures:
* Release process. Are Release Candidates used.
* Number of testers.
* Bug list. (No bugs might indicate that bugs are not being reported)
* Unit test code coverage.
* Automated tests passed.
* Number of features added to each release.
* User base
* User base of similar products


OPEN SOURCE
GEOSPATIAL
* Simple yes/no should answer this.

ENCOURAGE THE USE
This goes into training, presentations at conferences, inclusion in 
linux distrubutions etc.
This thread will want information about the project roadmap. When the 
next release will be out, what will be in it, will it be stable.
This will also require documentation about the project and knowledge 
about the validity of the documentation.
Then we need to monitor the success of our advertising.
Measures:
* Project roadmap
* Validity and completeness of project documentation
* Stability measures from above
* Number of downloads.
* Number of users (tracked by calls to WMS clients or similar)
* Number of users on email lists and similar

BUILD
COLLABORATIVE DEVELOPMENT
COMMUNITY
How strong is the community. How responsive is it? How effective is it? 
Is there commercial support? Is the control of the project open?
Measures:
* Number of emails
* Number of people asking questions
* Number of people answering questions
* Activity on IRC channels
* Number of SVN commits
* Number of wiki updates
* Number of organisations sponsoring the project
* Number of organisations offering commercial support

---
This has been a quick brainstorm - I'm sure there is more.
A lot of this information can be automatically collected. Then all we 
need is for Project Owners to review the data and provide commentry.
Eg: "The reason downloads has doubled is because we joined OSGeo and 
this increased our publicity". (This is actually what happened with 
Mapbuilder.)

Jody Garnett wrote:
> So then we run into the heart of the matter. Whom is this report being 
> generated for?
> 1. Is it a report the the board? Say tracking delays waiting for license 
> feedback? Or are we going after specific publicity or interoperability 
> goals ...
> 2. Is it a report to the "communication committees" (viscomm and 
> webcomm) with material for or notice of publicity activities?
> 3. Is it a report to the regional or task based committees? Describing 
> changes in project abilities etc...
> 
> To straighten this out we as the incubation committee need to crash a 
> few more meeting and see what expectations are, before annoying projects 
> with a request for quarterly reports.  I can think of a couple items I 
> would like to see (evidence of planning for example), but I have no idea 
> if they hold wider appeal.
> 
> Alternatively we can canvas the existing incubation projects and see 
> what artifacts they already produce and look for communality.
> 
> Cheers,
> Jody
> 
> Arnulf Christl wrote:
> 
>>> This may be minor, but would it be good if all projects could produce
>>> monthly status reports outlining key developments, improvements,
>>> roadblocks - perhaps number of squashed bugs or something like that.
>>> This could serve as a metric for monitoring project activity - but
>>> can also serve as a source for a consolidate 'news' or community
>>> update.  This would help encourage projects to continue to be active
>>> and a good way to keep the board informed of growing issues.
>>>
>>> Tyler
>>>     
>>
>>
>> This was what I had in mind although it would not really be any kind of
>> control as the reporting member would usually have stakes in the project
>> and could choose to simply not report problems. Obviously we should be
>> able to trust projects but then we must be aware that it is not a
>> 'control' thing anymore.
>>
>> I would really really suggest to keep it at the 3 month term as Cameron
>> suggests, also from the perspective of those having to digest and 
>> evaluate
>> the information.
>>
>> Regards,
>>
>>   
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
> For additional commands, e-mail: incubator-help at incubator.osgeo.org
> 
> 


-- 
Cameron Shorter
http://cameron.shorter.net