List of projects in incubation/r&d?

[David Horwitz]

Hi All,

Is there a list anywhere of projects that are in incubation/R&D (i.e.
have been through the formal proccess in some way)? I looked in the
management space and it seems the only way to get this is to go through
the PC minutes etc.

(I'm looking at to make sure that the incubation projects are being
built by Hudson)


D
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Stephen Marquard]

This page seems to cover it:

http://confluence.sakaiproject.org/display/MGT/Development+Efforts

except for R&D projects though they haven't gone through any formal process (nor are required to do so).

Regards
Stephen

>>> David Horwitz <[hidden email]> 5/14/2010 1:10 PM >>>
Hi All,

Is there a list anywhere of projects that are in incubation/R&D (i.e.
have been through the formal proccess in some way)? I looked in the
management space and it seems the only way to get this is to go through
the PC minutes etc.

(I'm looking at to make sure that the incubation projects are being
built by Hudson)


D
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management 

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"


 
______________________________________________________________________________________________

UNIVERSITY OF CAPE TOWN

This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from [phone]. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.

_____________________________________________________________________________________________________
 
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[David Horwitz]

Thanks was only missing Tiny URL service:

http://confluence.sakaiproject.org/display/MGT/Development+Efforts

(I know gradebook2 is in the wrong place :-)

and the Sakai 3 related projects have their own tab:

http://builds.sakaiproject.org:8080/view/Sakai%203/

While the R&D tabs contains a couple of projects that I've been asked to
add or that may come under consideration (blog2, mailsender) for
instance by being noted in the deprecation notes.

http://builds.sakaiproject.org:8080/view/RnD/


The "maintance" (this is an inacurate designation IMHO) are under the
indie tools section:
http://builds.sakaiproject.org:8080/view/Sakai%202%20Indie%20Tools/

D



On 05/14/2010 01:17 PM, Stephen Marquard wrote:

> This page seems to cover it:
>
> http://confluence.sakaiproject.org/display/MGT/Development+Efforts
>
> except for R&D projects though they haven't gone through any formal process (nor are required to do so).
>
> Regards
> Stephen
>
>  
>>>> David Horwitz <[hidden email]> 5/14/2010 1:10 PM >>>
>>>>        
> Hi All,
>
> Is there a list anywhere of projects that are in incubation/R&D (i.e.
> have been through the formal proccess in some way)? I looked in the
> management space and it seems the only way to get this is to go through
> the PC minutes etc.
>
> (I'm looking at to make sure that the incubation projects are being
> built by Hudson)
>
>
> D
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management 
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>
>
>  
> ______________________________________________________________________________________________
>
> UNIVERSITY OF CAPE TOWN
>
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from [phone]. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
>
> _____________________________________________________________________________________________________
>  
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>  

_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Steve Swinsburg-3]

Don't put TinyUrlService into Hudson, it's current form has been deprecated.. When I get a spare moment I'll get the new version up.

More info if you fancy:
http://steve-on-sakai.blogspot.com/2009/12/tinyurlservice-10-released.html

cheers,
Steve



On 14/05/2010, at 9:36 PM, David Horwitz wrote:

> Thanks was only missing Tiny URL service:
>
> http://confluence.sakaiproject.org/display/MGT/Development+Efforts
>
> (I know gradebook2 is in the wrong place :-)
>
> and the Sakai 3 related projects have their own tab:
>
> http://builds.sakaiproject.org:8080/view/Sakai%203/
>
> While the R&D tabs contains a couple of projects that I've been asked to
> add or that may come under consideration (blog2, mailsender) for
> instance by being noted in the deprecation notes.
>
> http://builds.sakaiproject.org:8080/view/RnD/
>
>
> The "maintance" (this is an inacurate designation IMHO) are under the
> indie tools section:
> http://builds.sakaiproject.org:8080/view/Sakai%202%20Indie%20Tools/
>
> D
>
>
>
> On 05/14/2010 01:17 PM, Stephen Marquard wrote:
>> This page seems to cover it:
>>
>> http://confluence.sakaiproject.org/display/MGT/Development+Efforts
>>
>> except for R&D projects though they haven't gone through any formal process (nor are required to do so).
>>
>> Regards
>> Stephen
>>
>>
>>>>> David Horwitz <[hidden email]> 5/14/2010 1:10 PM >>>
>>>>>
>> Hi All,
>>
>> Is there a list anywhere of projects that are in incubation/R&D (i.e.
>> have been through the formal proccess in some way)? I looked in the
>> management space and it seems the only way to get this is to go through
>> the PC minutes etc.
>>
>> (I'm looking at to make sure that the incubation projects are being
>> built by Hudson)
>>
>>
>> D
>> _______________________________________________
>> management mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/management 
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>
>>
>>
>> ______________________________________________________________________________________________
>>
>> UNIVERSITY OF CAPE TOWN
>>
>> This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from [phone]. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
>>
>> _____________________________________________________________________________________________________
>>
>> _______________________________________________
>> management mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/management
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[David Horwitz]

OK what i've done is left the project there with a note (and a link to
the blog) but disabled (i.e. hudson won't actulay try build it again)

D

On 05/14/2010 01:40 PM, Steve Swinsburg wrote:

> Don't put TinyUrlService into Hudson, it's current form has been deprecated.. When I get a spare moment I'll get the new version up.
>
> More info if you fancy:
> http://steve-on-sakai.blogspot.com/2009/12/tinyurlservice-10-released.html
>
> cheers,
> Steve
>
>
>
> On 14/05/2010, at 9:36 PM, David Horwitz wrote:
>
>  
>> Thanks was only missing Tiny URL service:
>>
>> http://confluence.sakaiproject.org/display/MGT/Development+Efforts
>>
>> (I know gradebook2 is in the wrong place :-)
>>
>> and the Sakai 3 related projects have their own tab:
>>
>> http://builds.sakaiproject.org:8080/view/Sakai%203/
>>
>> While the R&D tabs contains a couple of projects that I've been asked to
>> add or that may come under consideration (blog2, mailsender) for
>> instance by being noted in the deprecation notes.
>>
>> http://builds.sakaiproject.org:8080/view/RnD/
>>
>>
>> The "maintance" (this is an inacurate designation IMHO) are under the
>> indie tools section:
>> http://builds.sakaiproject.org:8080/view/Sakai%202%20Indie%20Tools/
>>
>> D
>>
>>
>>
>> On 05/14/2010 01:17 PM, Stephen Marquard wrote:
>>    
>>> This page seems to cover it:
>>>
>>> http://confluence.sakaiproject.org/display/MGT/Development+Efforts
>>>
>>> except for R&D projects though they haven't gone through any formal process (nor are required to do so).
>>>
>>> Regards
>>> Stephen
>>>
>>>
>>>      
>>>>>> David Horwitz <[hidden email]> 5/14/2010 1:10 PM >>>
>>>>>>
>>>>>>            
>>> Hi All,
>>>
>>> Is there a list anywhere of projects that are in incubation/R&D (i.e.
>>> have been through the formal proccess in some way)? I looked in the
>>> management space and it seems the only way to get this is to go through
>>> the PC minutes etc.
>>>
>>> (I'm looking at to make sure that the incubation projects are being
>>> built by Hudson)
>>>
>>>
>>> D
>>> _______________________________________________
>>> management mailing list
>>> [hidden email]
>>> http://collab.sakaiproject.org/mailman/listinfo/management 
>>>
>>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>>
>>>
>>>
>>> ______________________________________________________________________________________________
>>>
>>> UNIVERSITY OF CAPE TOWN
>>>
>>> This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from [phone]. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
>>>
>>> _____________________________________________________________________________________________________
>>>
>>> _______________________________________________
>>> management mailing list
>>> [hidden email]
>>> http://collab.sakaiproject.org/mailman/listinfo/management
>>>
>>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>>
>>>      
>> _______________________________________________
>> management mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/management
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>    
>  

_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Jean-Francois Leveque]

I think the table is incomplete. Or maybe other stages are needed.

Without other stages, we should have Profile2 1.3 under maintenance and
Profile2 1.4 under R&D. Same applies to Site Stats 2.1 and 2.2, BasicLTI
1.1 and 1.2.

Is Conditional Release embedded?

Why isn't there a different table for Sakai 3 development? All the other
development is for Sakai 2.7 or later minor release, not Sakai 3 AFAICT.

When will the Product Council evaluation of development be done for
Sakai 2.8?

Is there an equivalent table for development that got into Sakai before
2.7? It seems the PC is only involved in what gets in, not what has to
get out, been kept but deprecated for at least a release or still has to
be maintained one way or the other.

J-F

David Horwitz a écrit :

> Thanks was only missing Tiny URL service:
>
> http://confluence.sakaiproject.org/display/MGT/Development+Efforts
>
> (I know gradebook2 is in the wrong place :-)
>
> and the Sakai 3 related projects have their own tab:
>
> http://builds.sakaiproject.org:8080/view/Sakai%203/
>
> While the R&D tabs contains a couple of projects that I've been asked to
> add or that may come under consideration (blog2, mailsender) for
> instance by being noted in the deprecation notes.
>
> http://builds.sakaiproject.org:8080/view/RnD/
>
>
> The "maintance" (this is an inacurate designation IMHO) are under the
> indie tools section:
> http://builds.sakaiproject.org:8080/view/Sakai%202%20Indie%20Tools/
>
> D
>
>
>
> On 05/14/2010 01:17 PM, Stephen Marquard wrote:
>> This page seems to cover it:
>>
>> http://confluence.sakaiproject.org/display/MGT/Development+Efforts
>>
>> except for R&D projects though they haven't gone through any formal process (nor are required to do so).
>>
>> Regards
>> Stephen
>>
>>  
>>>>> David Horwitz <[hidden email]> 5/14/2010 1:10 PM >>>
>>>>>        
>> Hi All,
>>
>> Is there a list anywhere of projects that are in incubation/R&D (i.e.
>> have been through the formal proccess in some way)? I looked in the
>> management space and it seems the only way to get this is to go through
>> the PC minutes etc.
>>
>> (I'm looking at to make sure that the incubation projects are being
>> built by Hudson)David Horwitz <[hidden email]>
>>
>>
>> D
>> _______________________________________________
>> management mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/management 
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>
>>
>>  
>> ______________________________________________________________________________________________
>>
>> UNIVERSITY OF CAPE TOWN
>>
>> This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from [phone]. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
>>
>> _____________________________________________________________________________________________________
>>  
>> _______________________________________________
>> management mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/management
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>  
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Clay Fenlason]

On Fri, May 14, 2010 at 9:16 AM, Jean-Francois Leveque
<[hidden email]> wrote:
> I think the table is incomplete. Or maybe other stages are needed.
>
> Without other stages, we should have Profile2 1.3 under maintenance and
> Profile2 1.4 under R&D. Same applies to Site Stats 2.1 and 2.2, BasicLTI
> 1.1 and 1.2.

We (a Product Council 'we') haven't yet tried to treat point-releases.
Only entirely new generations of product (ground-up rewrites like
Profile 2, GB 2, Sakai 3) have been tackled thus far. It's a good
question what level of change should involve the full cycle of review
- I'm inclined to think that the difference between, for example, Site
Stats 2.1 and 2.2 needs a lighter-weight process than the full cycle.
This is the kind of question I think the project coordination
discussions will need to take up, and we should have some talk about
it on-list ahead of time.

> Is Conditional Release embedded?

I'm not sure what you mean, but I'm going to guess that the answer to
the question is that it is not an independent tool, it introduces
capabilities that other tools make use of. It is disabled by default
in 2.7, and if it is turned on it is only the Resources and Gradebook
tools which will make use of it.

> Why isn't there a different table for Sakai 3 development?

Because Sakai 3 is its own, whole project, with unitary criteria for
success and failure at this stage. It's likely in future that there
will be separable components that will be treated as development
projects on their own terms, but it's not there yet. There is a
consensus that the Sakai 3 work is best treated as a single thing with
tight collaboration for now.

> All the other
> development is for Sakai 2.7 or later minor release, not Sakai 3 AFAICT.
>
> When will the Product Council evaluation of development be done for
> Sakai 2.8?

We (and this is not merely a Product Council 'we') need to start
talking seriously about the Sakai 2 roadmap, in a way that makes the
case for having a 2.8 in the first place, and takes available resource
into account in any planning. My aim is to come to some resolution on
these questions by or around the time of the conference, and I'm going
to try to begin to initiate some of these discussions on sakai-dev in
the next few days.

> Is there an equivalent table for development that got into Sakai before
> 2.7? It seems the PC is only involved in what gets in, not what has to
> get out, been kept but deprecated for at least a release or still has to
> be maintained one way or the other.

This table is focused on the projects that have gone through some
formal stage of the process. It's true that we haven't worked this out
for deprecation as yet, and should treat those questions better for a
presumed 2.8. At the moment I'm attracted to the model where the
maintenance team makes deprecation recommendations, there is community
discussion about these, and the PC weighs these points against
functional impact where necessary.

~Clay
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Clay Fenlason]

On Fri, May 14, 2010 at 7:36 AM, David Horwitz <[hidden email]> wrote:
> Thanks was only missing Tiny URL service:
>
> http://confluence.sakaiproject.org/display/MGT/Development+Efforts
>
> (I know gradebook2 is in the wrong place :-)

It might be in the wrong place, but where it is now is deliberate, so
let me explain the reasons and we can spot their flaws together.

All those tools/capabilities considered for 2.7 were basically
completed development work: we (the PC) were trying to make a start in
applying the process to projects already well down the line. To that
extent, it seemed that we were picking them up already at the end of
the product development stage. [1]

As a point of comparison, TinyURLService had fundamental questions
raised about it, and it was understood that Steve Swinsburg was going
to go back to the drawing board on a few points, and so returning it
to incubation for a new round of development seemed the most accurate
thing.

Gradebook 2 could not be included in a Sakai distribution for
licensing reasons, but there were no plans to do a significant rewrite
around this issue (eg. by using a different GWT library for its
interface) so there wasn't a real reason to say that it was going to
go through a new product development phase, and go back to incubation.
I think we and the UCDavis team were hoping a solution might be worked
out given time, but we need to pick up this thread of discussion with
the UCDavis team again - they may want to continue to develop the tool
independently of Sakai releases, but we haven't had more conversation
about this, so I don't want to go further and speak out of turn just
now - and in the interim the conservative answer has been to leave it
where it was.

wdyt?

~Clay

[1] http://confluence.sakaiproject.org//x/sgTtAw
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[David Horwitz]

Hi Clay,

Was not making a dig that about the Status of GB2 - was merely
acknowledging that while I had made an effort to represent the community
process there where limitations on how this was reflected  in the Hudson
categories (c.f similarly that the Sakai 3 projects are in their own
tab). The comment was to forstall you should have a "product" tab....

D

On 05/14/2010 05:16 PM, Clay Fenlason wrote:

> On Fri, May 14, 2010 at 7:36 AM, David Horwitz <[hidden email]> wrote:
>  
>> Thanks was only missing Tiny URL service:
>>
>> http://confluence.sakaiproject.org/display/MGT/Development+Efforts
>>
>> (I know gradebook2 is in the wrong place :-)
>>    
> It might be in the wrong place, but where it is now is deliberate, so
> let me explain the reasons and we can spot their flaws together.
>
> All those tools/capabilities considered for 2.7 were basically
> completed development work: we (the PC) were trying to make a start in
> applying the process to projects already well down the line. To that
> extent, it seemed that we were picking them up already at the end of
> the product development stage. [1]
>
> As a point of comparison, TinyURLService had fundamental questions
> raised about it, and it was understood that Steve Swinsburg was going
> to go back to the drawing board on a few points, and so returning it
> to incubation for a new round of development seemed the most accurate
> thing.
>
> Gradebook 2 could not be included in a Sakai distribution for
> licensing reasons, but there were no plans to do a significant rewrite
> around this issue (eg. by using a different GWT library for its
> interface) so there wasn't a real reason to say that it was going to
> go through a new product development phase, and go back to incubation.
> I think we and the UCDavis team were hoping a solution might be worked
> out given time, but we need to pick up this thread of discussion with
> the UCDavis team again - they may want to continue to develop the tool
> independently of Sakai releases, but we haven't had more conversation
> about this, so I don't want to go further and speak out of turn just
> now - and in the interim the conservative answer has been to leave it
> where it was.
>
> wdyt?
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/sgTtAw
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>  

_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Clay Fenlason]

Right, didn't mean to take it as a dig, but I did want to use it as an
occasion to think through why things are where they are, to try to
clarify and perhaps spark some dialogue about how this is playing out.

~Clay

On Fri, May 14, 2010 at 11:28 AM, David Horwitz <[hidden email]> wrote:

> Hi Clay,
>
> Was not making a dig that about the Status of GB2 - was merely
> acknowledging that while I had made an effort to represent the community
> process there where limitations on how this was reflected  in the Hudson
> categories (c.f similarly that the Sakai 3 projects are in their own
> tab). The comment was to forstall you should have a "product" tab....
>
> D
>
> On 05/14/2010 05:16 PM, Clay Fenlason wrote:
>> On Fri, May 14, 2010 at 7:36 AM, David Horwitz <[hidden email]> wrote:
>>
>>> Thanks was only missing Tiny URL service:
>>>
>>> http://confluence.sakaiproject.org/display/MGT/Development+Efforts
>>>
>>> (I know gradebook2 is in the wrong place :-)
>>>
>> It might be in the wrong place, but where it is now is deliberate, so
>> let me explain the reasons and we can spot their flaws together.
>>
>> All those tools/capabilities considered for 2.7 were basically
>> completed development work: we (the PC) were trying to make a start in
>> applying the process to projects already well down the line. To that
>> extent, it seemed that we were picking them up already at the end of
>> the product development stage. [1]
>>
>> As a point of comparison, TinyURLService had fundamental questions
>> raised about it, and it was understood that Steve Swinsburg was going
>> to go back to the drawing board on a few points, and so returning it
>> to incubation for a new round of development seemed the most accurate
>> thing.
>>
>> Gradebook 2 could not be included in a Sakai distribution for
>> licensing reasons, but there were no plans to do a significant rewrite
>> around this issue (eg. by using a different GWT library for its
>> interface) so there wasn't a real reason to say that it was going to
>> go through a new product development phase, and go back to incubation.
>> I think we and the UCDavis team were hoping a solution might be worked
>> out given time, but we need to pick up this thread of discussion with
>> the UCDavis team again - they may want to continue to develop the tool
>> independently of Sakai releases, but we haven't had more conversation
>> about this, so I don't want to go further and speak out of turn just
>> now - and in the interim the conservative answer has been to leave it
>> where it was.
>>
>> wdyt?
>>
>> ~Clay
>>
>> [1] http://confluence.sakaiproject.org//x/sgTtAw
>> _______________________________________________
>> management mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/management
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>

_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Jean-Francois Leveque]

Clay Fenlason a écrit :

>>
>> When will the Product Council evaluation of development be done for
>> Sakai 2.8?
>
> We (and this is not merely a Product Council 'we') need to start
> talking seriously about the Sakai 2 roadmap, in a way that makes the
> case for having a 2.8 in the first place, and takes available resource
> into account in any planning. My aim is to come to some resolution on
> these questions by or around the time of the conference, and I'm going
> to try to begin to initiate some of these discussions on sakai-dev in
> the next few days.

Seems the PC current membership mandate lasts until "2.8 is released".
This must mean that 2.8 will be released. I don't think we can say 2.8
will not be released because 3.0.0 has not been released yet, AFAICT,
and might not be released before 2.7.0 is.

People are still working on trunk, which means they're already working
on a 2.8 release unless they're working on a independently released part
of Sakai. Maybe they should have been told this before 2.7 was branched
from trunk, don't you think?

>> Is there an equivalent table for development that got into Sakai before
>> 2.7? It seems the PC is only involved in what gets in, not what has to
>> get out, been kept but deprecated for at least a release or still has to
>> be maintained one way or the other.
>
> This table is focused on the projects that have gone through some
> formal stage of the process. It's true that we haven't worked this out
> for deprecation as yet, and should treat those questions better for a
> presumed 2.8. At the moment I'm attracted to the model where the
> maintenance team makes deprecation recommendations, there is community
> discussion about these, and the PC weighs these points against
> functional impact where necessary.
>
> ~Clay

I couldn't agree more with you on this one and less on the "presumed" part.

Does the PC have resources to really weigh its decisions?

The Maintenance Team is only working on unmaintained code, AFAICT.

How does the PC detect the code is currently not maintained?

How does the PC detect code will not be maintained ?

J-F
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[David Horwitz]

> Only entirely new generations of product (ground-up rewrites like
> Profile 2, GB 2, Sakai 3) have been tackled thus far. It's a good
> question what level of change should involve the full cycle of review
> - I'm inclined to think that the difference between, for example, Site
> Stats 2.1 and 2.2 needs a lighter-weight process than the full cycle.
> This is the kind of question I think the project coordination
> discussions will need to take up, and we should have some talk about
> it on-list ahead of time.
>
>  

Interestingly when I suggested that if new features wanted to be added
to tools in maintenance (as understood by the MT not the PC)* I was
pretty much told that the PC didn't see that as a need for their
involvement, at least that's how I understood the answers I got when I
asked last year. I used the example of email archive and suggested that
someone who wanted to add a significant feature to it should have to
have a plan and resources and the PC should be the one to evaluate this.
As I understood the responses I got from PC members they did not see
this as a function they could or should perform. It seems puzzling then
to suggest that a newly promoted tool that should have a roadmap from
its promotion and has an active team developing it should.

* this is why I think the roadmap shouldn't use release and maintenance
the way it does.

D
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Clay Fenlason]

On Fri, May 14, 2010 at 12:00 PM, David Horwitz <[hidden email]> wrote:

>
>> Only entirely new generations of product (ground-up rewrites like
>> Profile 2, GB 2, Sakai 3) have been tackled thus far. It's a good
>> question what level of change should involve the full cycle of review
>> - I'm inclined to think that the difference between, for example, Site
>> Stats 2.1 and 2.2 needs a lighter-weight process than the full cycle.
>> This is the kind of question I think the project coordination
>> discussions will need to take up, and we should have some talk about
>> it on-list ahead of time.
>>
>>
> Interestingly when I suggested that if new features wanted to be added
> to tools in maintenance (as understood by the MT not the PC)* I was
> pretty much told that the PC didn't see that as a need for their
> involvement, at least that's how I understood the answers I got when I
> asked last year. I used the example of email archive and suggested that
> someone who wanted to add a significant feature to it should have to
> have a plan and resources and the PC should be the one to evaluate this.
> As I understood the responses I got from PC members they did not see
> this as a function they could or should perform.

I think that's accurate, and I think it's still the general feeling.
When I say a "lighter-weight process" I'm including in that the
possibility that the PC does not play a role. I'm expecting that some
of the recommendations that come back from the review process might
touch on this point, so I'm leaving a little extra room for this to
change (from the answers you got last year).

> It seems puzzling then
> to suggest that a newly promoted tool that should have a roadmap from
> its promotion and has an active team developing it should.
>
> * this is why I think the roadmap shouldn't use release and maintenance
> the way it does.

I don't think I follow, exactly, but my best interpretation is: there
are things in release state that still have active development and
roadmaps, and 'maintenance' is best used to describe some
functionality that is simply seeing bugfixes, and not new features ...
is that it?

~Clay
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Clay Fenlason]

I think you're misunderstanding me, J-F.

On Fri, May 14, 2010 at 11:55 AM, Jean-Francois Leveque
<[hidden email]> wrote:

> Clay Fenlason a écrit :
>>>
>>> When will the Product Council evaluation of development be done for
>>> Sakai 2.8?
>>
>> We (and this is not merely a Product Council 'we') need to start
>> talking seriously about the Sakai 2 roadmap, in a way that makes the
>> case for having a 2.8 in the first place, and takes available resource
>> into account in any planning. My aim is to come to some resolution on
>> these questions by or around the time of the conference, and I'm going
>> to try to begin to initiate some of these discussions on sakai-dev in
>> the next few days.
>
> Seems the PC current membership mandate lasts until "2.8 is released". This
> must mean that 2.8 will be released. I don't think we can say 2.8 will not
> be released because 3.0.0 has not been released yet, AFAICT, and might not
> be released before 2.7.0 is.

I didn't say that 2.8 will not be released. What I did try to say is
that we as a community should make a positive decision to have a 2.8,
plan for it with a known scope of change and set of resources, and
know what we're getting into before we undertake a new release cycle
(rather than just assuming that current momentum will carry us
through).

~Clay
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Stephen Marquard]

I'm coming to the conclusion that we should replace the management list
with an autoresponder that says:

"There is no 'they'. Do it yourself."

Regards
Stephen
 
>>> Jean-Francois Leveque <[hidden email]> 5/14/2010
5:55 PM >>>
Clay Fenlason a écrit :
>>
>> When will the Product Council evaluation of development be done for
>> Sakai 2.8?
>
> We (and this is not merely a Product Council 'we') need to start
> talking seriously about the Sakai 2 roadmap, in a way that makes the
> case for having a 2.8 in the first place, and takes available
resource
> into account in any planning. My aim is to come to some resolution
on
> these questions by or around the time of the conference, and I'm
going
> to try to begin to initiate some of these discussions on sakai-dev
in
> the next few days.

Seems the PC current membership mandate lasts until "2.8 is released".

This must mean that 2.8 will be released. I don't think we can say 2.8

will not be released because 3.0.0 has not been released yet, AFAICT,
and might not be released before 2.7.0 is.

People are still working on trunk, which means they're already working

on a 2.8 release unless they're working on a independently released
part
of Sakai. Maybe they should have been told this before 2.7 was branched

from trunk, don't you think?

>> Is there an equivalent table for development that got into Sakai
before
>> 2.7? It seems the PC is only involved in what gets in, not what has
to
>> get out, been kept but deprecated for at least a release or still
has to
>> be maintained one way or the other.
>
> This table is focused on the projects that have gone through some
> formal stage of the process. It's true that we haven't worked this
out
> for deprecation as yet, and should treat those questions better for
a
> presumed 2.8. At the moment I'm attracted to the model where the
> maintenance team makes deprecation recommendations, there is
community
> discussion about these, and the PC weighs these points against
> functional impact where necessary.
>
> ~Clay

I couldn't agree more with you on this one and less on the "presumed"
part.

Does the PC have resources to really weigh its decisions?

The Maintenance Team is only working on unmaintained code, AFAICT.

How does the PC detect the code is currently not maintained?

How does the PC detect code will not be maintained ?

J-F
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to
[hidden email] with a subject of
"unsubscribe"



 

########################################################################
UNIVERSITY OF CAPE TOWN

This e-mail is subject to the UCT ICT policies and e-mail disclaimer
published on our website at
http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from
[phone]. This e-mail is intended only for the person(s) to whom
it is addressed. If the e-mail has reached you in error, please notify
the author. If you are not the intended recipient of the e-mail you may
not use, disclose, copy, redirect or print the content. If this e-mail
is not related to the business of UCT it is sent by the sender in the
sender's individual capacity.

########################################################################
 
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[David Horwitz]

>> It seems puzzling then
>> to suggest that a newly promoted tool that should have a roadmap from
>> its promotion and has an active team developing it should.
>>
>> * this is why I think the roadmap shouldn't use release and maintenance
>> the way it does.
>>    
> I don't think I follow, exactly, but my best interpretation is: there
> are things in release state that still have active development and
> roadmaps, and 'maintenance' is best used to describe some
> functionality that is simply seeing bugfixes, and not new features ...
> is that it?
>
>  

yes. Let me expand and suggest a nomenclature:

1) product ready (equiv to current Maintenance on product lifecycle)
    a)  feature is ready for review by the QA and release teams for an
upcoming Sakai release there exists an active team supporting it
    b) tools that have gone past (a) but are still under the care of a
team who continue to develop it in terms of some radmap

2) Maintenance:
    - Feature is mature (has been in several sakai releases) and:
            a) there are no plans to add new features
            b) and/or there is no active team supporting
            c) is likely under the care of the maintance team

By conflating the 2 I think we ingore the risks when a tool moves from
1->2 and potentially back again.  While the PC may or may not be
interested in the 1->2 move it would seem to me that it may well have an
interest in the 2->1 move

I would avoid the term "released" as well due to obvious scope for confusion

D



> ~Clay
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>  
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Noah Botimer]

I think 2.8 has been harmed by this ambiguity. 2.7 has been feature-frozen since sometime in Q3-4 2009. So, what if I want to work on new stuff? What about the work I've been doing in trunk since October?

Hearing now that there may or may not be a way for my stuff to be released is really discouraging. (As close as I am to this, it isn't abrupt to me, but I'd wager that it would be to many contributors.)

Hearing that I might need to do some QA/RM work that has historically been "handled" is a change, but one that I can understand and seek resources/time for.

There are features in trunk-purgatory now. I've already written that I think a regularly scheduled 2.8 is the only responsible path.

If that means a typical schedule of feature freeze in ~August, code freeze in ~November, release in ~May, without big changes to how QA/RM happens, we need to know that.

If it means freezing trunk very soon and rallying stand-in resources for QA/RM, we need to know that.

If it means that 2.7.x instantaneously becomes 2.8.x and we cherry-pick a couple of features from the trunk that magically represents 2.9 or 2.never, we need to know that.

There are just too many adopters and stakeholders to back into an already-late decision about 2.8 here.

Thanks,
-Noah


P.S. I say "I" and "my" here, but I mean "we" as in anyone moving forward on trunk under the only sane conclusion -- that, in the absence of a clearly communicated new pattern, features should be checked into trunk, same as ever.


On May 14, 2010, at 9:41 AM, Clay Fenlason wrote:

> I think you're misunderstanding me, J-F.
>
> On Fri, May 14, 2010 at 11:55 AM, Jean-Francois Leveque
> <[hidden email]> wrote:
>> Clay Fenlason a écrit :
>>>>
>>>> When will the Product Council evaluation of development be done for
>>>> Sakai 2.8?
>>>
>>> We (and this is not merely a Product Council 'we') need to start
>>> talking seriously about the Sakai 2 roadmap, in a way that makes the
>>> case for having a 2.8 in the first place, and takes available resource
>>> into account in any planning. My aim is to come to some resolution on
>>> these questions by or around the time of the conference, and I'm going
>>> to try to begin to initiate some of these discussions on sakai-dev in
>>> the next few days.
>>
>> Seems the PC current membership mandate lasts until "2.8 is released". This
>> must mean that 2.8 will be released. I don't think we can say 2.8 will not
>> be released because 3.0.0 has not been released yet, AFAICT, and might not
>> be released before 2.7.0 is.
>
> I didn't say that 2.8 will not be released. What I did try to say is
> that we as a community should make a positive decision to have a 2.8,
> plan for it with a known scope of change and set of resources, and
> know what we're getting into before we undertake a new release cycle
> (rather than just assuming that current momentum will carry us
> through).
>
> ~Clay
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Clay Fenlason]

You've listed off a number of things that we need to know - I think
this is what I'm arguing for. I'm talking about making sound plans and
garnering resource commitments to get us to a 2.8 release. We need to
plan around what 2.8 should accomplish, what effort will be required
to see it through, what resources we have to bring to bear, and make
the tradeoffs clear in order to either make a concrete call for
stronger commitments, or make the case for a change in schedule,
scope, what have you. We need to bring the same discipline to 2.8
planning that we're insisting on for new projects.

If I call attention to the risks by saying we might not have a 2.8 if
we fail to commit ourselves adequately (and the same goes for 3.0), I
don't think that's introducing ambiguity. Nor do I think it's more
alarming than it should be. I think we need to face this squarely,
whether it's late or not, and that seems to me the responsible thing.

~Clay

On Fri, May 14, 2010 at 2:58 PM, Noah Botimer <[hidden email]> wrote:

> I think 2.8 has been harmed by this ambiguity. 2.7 has been feature-frozen since sometime in Q3-4 2009. So, what if I want to work on new stuff? What about the work I've been doing in trunk since October?
>
> Hearing now that there may or may not be a way for my stuff to be released is really discouraging. (As close as I am to this, it isn't abrupt to me, but I'd wager that it would be to many contributors.)
>
> Hearing that I might need to do some QA/RM work that has historically been "handled" is a change, but one that I can understand and seek resources/time for.
>
> There are features in trunk-purgatory now. I've already written that I think a regularly scheduled 2.8 is the only responsible path.
>
> If that means a typical schedule of feature freeze in ~August, code freeze in ~November, release in ~May, without big changes to how QA/RM happens, we need to know that.
>
> If it means freezing trunk very soon and rallying stand-in resources for QA/RM, we need to know that.
>
> If it means that 2.7.x instantaneously becomes 2.8.x and we cherry-pick a couple of features from the trunk that magically represents 2.9 or 2.never, we need to know that.
>
> There are just too many adopters and stakeholders to back into an already-late decision about 2.8 here.
>
> Thanks,
> -Noah
>
>
> P.S. I say "I" and "my" here, but I mean "we" as in anyone moving forward on trunk under the only sane conclusion -- that, in the absence of a clearly communicated new pattern, features should be checked into trunk, same as ever.
>
>
> On May 14, 2010, at 9:41 AM, Clay Fenlason wrote:
>
>> I think you're misunderstanding me, J-F.
>>
>> On Fri, May 14, 2010 at 11:55 AM, Jean-Francois Leveque
>> <[hidden email]> wrote:
>>> Clay Fenlason a écrit :
>>>>>
>>>>> When will the Product Council evaluation of development be done for
>>>>> Sakai 2.8?
>>>>
>>>> We (and this is not merely a Product Council 'we') need to start
>>>> talking seriously about the Sakai 2 roadmap, in a way that makes the
>>>> case for having a 2.8 in the first place, and takes available resource
>>>> into account in any planning. My aim is to come to some resolution on
>>>> these questions by or around the time of the conference, and I'm going
>>>> to try to begin to initiate some of these discussions on sakai-dev in
>>>> the next few days.
>>>
>>> Seems the PC current membership mandate lasts until "2.8 is released". This
>>> must mean that 2.8 will be released. I don't think we can say 2.8 will not
>>> be released because 3.0.0 has not been released yet, AFAICT, and might not
>>> be released before 2.7.0 is.
>>
>> I didn't say that 2.8 will not be released. What I did try to say is
>> that we as a community should make a positive decision to have a 2.8,
>> plan for it with a known scope of change and set of resources, and
>> know what we're getting into before we undertake a new release cycle
>> (rather than just assuming that current momentum will carry us
>> through).
>>
>> ~Clay
>> _______________________________________________
>> management mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/management
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>
>

_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

[Jean-Francois Leveque]

I think I wasn't the only one misunderstanding you, Clay. It seems this
happened to people whose native language is English.

J-F

Clay Fenlason a écrit :

> I think you're misunderstanding me, J-F.
>
> On Fri, May 14, 2010 at 11:55 AM, Jean-Francois Leveque
> <[hidden email]> wrote:
>> Clay Fenlason a écrit :
>>>> When will the Product Council evaluation of development be done for
>>>> Sakai 2.8?
>>> We (and this is not merely a Product Council 'we') need to start
>>> talking seriously about the Sakai 2 roadmap, in a way that makes the
>>> case for having a 2.8 in the first place, and takes available resource
>>> into account in any planning. My aim is to come to some resolution on
>>> these questions by or around the time of the conference, and I'm going
>>> to try to begin to initiate some of these discussions on sakai-dev in
>>> the next few days.
>> Seems the PC current membership mandate lasts until "2.8 is released". This
>> must mean that 2.8 will be released. I don't think we can say 2.8 will not
>> be released because 3.0.0 has not been released yet, AFAICT, and might not
>> be released before 2.7.0 is.
>
> I didn't say that 2.8 will not be released. What I did try to say is
> that we as a community should make a positive decision to have a 2.8,
> plan for it with a known scope of change and set of resources, and
> know what we're getting into before we undertake a new release cycle
> (rather than just assuming that current momentum will carry us
> through).
>
> ~Clay

_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"