[Incubator] Branding/Sales information required in Graduation Template

Arnulf_Christl · October 23, 2006, 9:35pm

On Mon, October 23, 2006 00:57, Paul Spencer wrote:

We will also have to retro-actively ask MapBender for this information.

Paul

Paul,
we spell Mapbender with a small b because we are so humble. You as our
mentor should know. Tststs.

There is more to this, we have not really specified what happens to a
project once it is graduated, curently all processes simply stop, this
cannot be in our interest. We have addressed th bug tracker issue but
there is no control or agenda which would bring this up excpet the project
does it out of its own interest.

Regarding the Branding/Sales part of graduation I must confess that I
don't get it. Which is a slight problem because as VisCom member I could
probably provide for what you are asking. Its not that I want to play ping
pong with this issue but what exactly is it that you need from VisCom?

Regards, Arnulf

On 22-Oct-06, at 4:29 PM, Cameron Shorter wrote:

Jody made some very good points about the need for projects to
provide information for Branding/Sales as part of graduation.

This requirement is not in the graduation template which means that
Mapbuilder has not addressed it. (We do have some information, but
probably not enough).

It would be great if the Viscom could provide input into the
Graduation Template. I see this as being on the critcal path for
getting Mapbuilder to graduate.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: incubator-unsubscribe@incubator.osgeo.org
For additional commands, e-mail: incubator-help@incubator.osgeo.org

+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+

---------------------------------------------------------------------
To unsubscribe, e-mail: incubator-unsubscribe@incubator.osgeo.org
For additional commands, e-mail: incubator-help@incubator.osgeo.org

--
Arnulf Christl
http://www.ccgis.de

Jody_Garnett · October 23, 2006, 11:20pm

Arnulf Christl wrote:

Paul,
we spell Mapbender with a small b because we are so humble. You as our
mentor should know. Tststs.

There is more to this, we have not really specified what happens to a
project once it is graduated, curently all processes simply stop, this
cannot be in our interest. We have addressed th bug tracker issue but
there is no control or agenda which would bring this up excpet the project
does it out of its own interest.

I assume the webcomm is "responsible" here as that is the group you need to tell about your new bug tracker. After incubation a project is on its own w/ respect to communicating with the various committees. If the committees need to set up a process or two to handle this it will be the work of the next couple months.

Regarding the Branding/Sales part of graduation I must confess that I
don't get it. Which is a slight problem because as VisCom member I could
probably provide for what you are asking. Its not that I want to play ping
pong with this issue but what exactly is it that you need from VisCom?

Hi Arnulf, Probably time for me to chirp up again. On the webcom wiki I have listed several kinds of content that I would like to see created, I assume other groups such as viscom have similar "needs" - and that committee will need to make up its own mind about how to interact with projects.

Here are some links to the webcom discussion on content:
- http://wiki.osgeo.org/index.php/WebCom_OSGeo_Site_Focus#Format

This page documents the need for webcomm to provide projects with a care and feeding document:
- http://wiki.osgeo.org/index.php/WebCom_Scope

There has been discussion on needed content on the GeoTools email list, I will try and update this page to match:
- http://wiki.osgeo.org/index.php/GeoTools_Incubation_Progress

Cheers,
Jody

Jody_Garnett · October 23, 2006, 11:25pm

Arnulf Christl wrote:

Paul,
we spell Mapbender with a small b because we are so humble. You as our
mentor should know. Tststs.

There is more to this, we have not really specified what happens to a
project once it is graduated, curently all processes simply stop, this
cannot be in our interest. We have addressed th bug tracker issue but
there is no control or agenda which would bring this up excpet the project
does it out of its own interest.

I assume the webcomm is "responsible" here as that is the group you need
to tell about your new bug tracker. After incubation a project is on its
own w/ respect to communicating with the various committees. If the
committees need to set up a process or two to handle this it will be the
work of the next couple months.

Regarding the Branding/Sales part of graduation I must confess that I
don't get it. Which is a slight problem because as VisCom member I could
probably provide for what you are asking. Its not that I want to play ping
pong with this issue but what exactly is it that you need from VisCom?

Hi Arnulf, Probably time for me to chirp up again. On the webcom wiki I
have listed several kinds of content that I would like to see created, I
assume other groups such as viscom have similar "needs" - and that
committee will need to make up its own mind about how to interact with
projects.

Here are some links to the webcom discussion on content:
- http://wiki.osgeo.org/index.php/WebCom_OSGeo_Site_Focus#Format

This page documents the need for webcomm to provide projects with a care
and feeding document:
- http://wiki.osgeo.org/index.php/WebCom_Scope

There has been discussion on needed content on the GeoTools email list,
I will try and update this page to match:
- http://wiki.osgeo.org/index.php/GeoTools_Incubation_Progress

Cheers,
Jody

Tyler_Mitchell2 · October 24, 2006, 5:31am

On 23-Oct-06, at 2:35 PM, Arnulf Christl wrote:

There is more to this, we have not really specified what happens to a
project once it is graduated, curently all processes simply stop, this
cannot be in our interest. We have addressed th bug tracker issue but
there is no control or agenda which would bring this up excpet the project
does it out of its own interest.

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

Robert_Bray · October 24, 2006, 5:48am

We should probably have a template for that report. Do any of the existing projects already have some kind of status report we could use to kick start that process?

Bob

Tyler Mitchell wrote:

On 23-Oct-06, at 2:35 PM, Arnulf Christl wrote:

There is more to this, we have not really specified what happens to a
project once it is graduated, curently all processes simply stop, this
cannot be in our interest. We have addressed th bug tracker issue but
there is no control or agenda which would bring this up excpet the project
does it out of its own interest.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: incubator-unsubscribe@incubator.osgeo.org
For additional commands, e-mail: incubator-help@incubator.osgeo.org

Arnulf_Christl · October 24, 2006, 10:56pm

On Tue, October 24, 2006 07:31, Tyler Mitchell wrote:

On 23-Oct-06, at 2:35 PM, Arnulf Christl wrote:

There is more to this, we have not really specified what happens to a
project once it is graduated, curently all processes simply stop, this
cannot be in our interest. We have addressed th bug tracker issue but
there is no control or agenda which would bring this up excpet the
project
does it out of its own interest.

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,

--
Arnulf Christl
http://www.ccgis.de

Jody_Garnett · October 25, 2006, 12:31am

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,

Cameron_Shorter · October 25, 2006, 11:23am

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@incubator.osgeo.org
For additional commands, e-mail: incubator-help@incubator.osgeo.org

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