Thinking about Sakai 2.6 and 3.0

[Michael Korcuska]

Greetings,

In the weeks before, during and since Paris, a group of managers  
planning to commit staff time to the next set of releases have been  
discussing common interests and potential goals.  These conversations  
have grappled with a number of important issues including new user  
interface metaphors, a new and simpler kernel, replacement of some  
custom code with free open source alternatives and the place of social  
networking inside a learning/collaboration platform. Along the way,  
the group also discussed what it would like to have in the next  
release--a reflection that while it is important to talk about a big  
change we should also be focused on what is immediately in front of us.

So, it's time to get the results of this discussion published and get  
everyone involved. The following wiki page explains the ideas that  
have been discussed:

http://confluence.sakaiproject.org/confluence/x/VQAjAg

I've been involved in all of these discussions and feel that the plans  
outlined bring important and significant value to the 2.6 release  
while, at the same time, giving us a way forward to 3.0, which will  
allow us to make rapid and significant improvements in functionality,  
usability, quality, scalability and ease of development. Some of the  
2.6 items may need a bit more time and, therefore, we may want to  
extend code freeze by a few weeks.

A number of those involved in the conversations so far are willing and  
able to provide resources to execute against these plans. But we need  
more participation, certainly. The Sakai Foundation is able to offer  
UX leadership, project management support and quality assurance/
documentation help.

So...take a look. Make your comments. And let me know if you have  
resources (people or otherwise) that could help. This is a crucial  
time to get started on 3.0 and we definitely need additional resource.  
This is not just developer help...we need design, documentation, QA  
and project management.

Best regards,

Michael

--
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska@...
mobile: [phone] // phone: [phone]
skype: mkorcuska



--
  Michael Korcuska
  Executive Director, Sakai Foundation
  mkorcuska@...
  mobile: [phone] // phone: [phone]
  skype: mkorcuska


----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the Project: Portfolio site.
You can modify how you receive notifications at My Workspace > Preferences.

[Charles Hedrick]

This is a neat idea. However I have one major concern: One historical  
problem with quality in Sakai has been due to insufficient resources.  
I'd rather have a stodgy user interface that is well implemented than  
a snazzy one where there's wasn't enough staff time to get everything  
working properly. I'd like to make sure that there are really  
sufficient commitments before proceeding down this path.


On Aug 4, 2008, at 1:59 PM, Michael Korcuska wrote:

> Greetings,
>
> In the weeks before, during and since Paris, a group of managers
> planning to commit staff time to the next set of releases have been
> discussing common interests and potential goals. These conversations
> have grappled with a number of important issues including new user
> interface metaphors, a new and simpler kernel, replacement of some
> custom code with free open source alternatives and the place of social
> networking inside a learning/collaboration platform. Along the way,
> the group also discussed what it would like to have in the next
> release--a reflection that while it is important to talk about a big
> change we should also be focused on what is immediately in front of  
> us.
>
> So, it's time to get the results of this discussion published and get
> everyone involved. The following wiki page explains the ideas that
> have been discussed:
>
> http://confluence.sakaiproject.org/confluence/x/VQAjAg
>
> I've been involved in all of these discussions and feel that the plans
> outlined bring important and significant value to the 2.6 release
> while, at the same time, giving us a way forward to 3.0, which will
> allow us to make rapid and significant improvements in functionality,
> usability, quality, scalability and ease of development. Some of the
> 2.6 items may need a bit more time and, therefore, we may want to
> extend code freeze by a few weeks.
>
> A number of those involved in the conversations so far are willing and
> able to provide resources to execute against these plans. But we need
> more participation, certainly. The Sakai Foundation is able to offer
> UX leadership, project management support and quality assurance/
> documentation help.
>
> So...take a look. Make your comments. And let me know if you have
> resources (people or otherwise) that could help. This is a crucial
> time to get started on 3.0 and we definitely need additional resource.
> This is not just developer help...we need design, documentation, QA
> and project management.
>
> Best regards,
>
> Michael
>
> --
> Michael Korcuska
> Executive Director, Sakai Foundation
> mkorcuska@...
> mobile: [phone] // phone: [phone]
> skype: mkorcuska
>
>
>
> --
> Michael Korcuska
> Executive Director, Sakai Foundation
> mkorcuska@...
> mobile: [phone] // phone: [phone]
> skype: mkorcuska
>
>
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the DG: Development (a.k.a. sakai-dev) site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the Project: Portfolio site.
You can modify how you receive notifications at My Workspace > Preferences.

[Clay Fenlason-3]

It's a just concern, and one reflected in both the discussions and the
document.  It's for that reason that there's been a push for the
Foundation to provide project management coordination to make sure
we're taking on a scope which can be delivered.  Not every loose end
is tied, and some recruitment is still necessary, but enough
committments have been made that it seems no longer outrageous to
think that the plan (in rough outline) could be within reach.

There seem to be two simple ways to advance the product: the first is
to let everyone scratch their own itch and see what emerges;  the
second is to articulate a unifying vision and rally people to the
banner.  Granted that neither will work for us (if they work for
anybody) in those distilled forms, we nevertheless have a history of
tilting toward the former, and we've evinced a real difficulty doing
anything like creating a roadmap, for example, or constructing a
collaboration with more sophistication than the bilateral.  I've been
much encouraged by the beginning of these manager discussions to the
extent that they recognize that there are classes of problems that
call for more coordination, and they are critical for our future.

I have at times thought that our resource problems are as much matters
of coordination as questions of supply.  We waste energy on cures
rather than prevention, we don't give enough thought to how our
variegated issues are facets of a shared problem, we allow our choices
to deepen a reliance on a particular skillset (the Java architect
steeped in novel Sakai idioms), or we are too short-sighted about
design - both UX and technical.  If I prize this emerging roadmap it's
not for the details of its product vision (though I prize also that)
but because it signals to me a new level of maturity for our
collaboration - if it goes somewhere.  Our ability to agree and
execute upon a plan in this way seems to me really crucial.

So I think the resource question is central to the roadmap adumbrated
in the document, both in what it hopes to achieve (since many of the
hoped-for benefits include expanding our pool of available resource
and reducing burdens on existing resource) and what we need to get
there.

~Clay

On Mon, Aug 4, 2008 at 3:42 PM, Charles Hedrick <hedrick@...> wrote:

> This is a neat idea. However I have one major concern: One historical
> problem with quality in Sakai has been due to insufficient resources. I'd
> rather have a stodgy user interface that is well implemented than a snazzy
> one where there's wasn't enough staff time to get everything working
> properly. I'd like to make sure that there are really sufficient commitments
> before proceeding down this path.
>
> On Aug 4, 2008, at 1:59 PM, Michael Korcuska wrote:
>
> Greetings,
>
> In the weeks before, during and since Paris, a group of managers
> planning to commit staff time to the next set of releases have been
> discussing common interests and potential goals. These conversations
> have grappled with a number of important issues including new user
> interface metaphors, a new and simpler kernel, replacement of some
> custom code with free open source alternatives and the place of social
> networking inside a learning/collaboration platform. Along the way,
> the group also discussed what it would like to have in the next
> release--a reflection that while it is important to talk about a big
> change we should also be focused on what is immediately in front of us.
>
> So, it's time to get the results of this discussion published and get
> everyone involved. The following wiki page explains the ideas that
> have been discussed:
>
> http://confluence.sakaiproject.org/confluence/x/VQAjAg
>
> I've been involved in all of these discussions and feel that the plans
> outlined bring important and significant value to the 2.6 release
> while, at the same time, giving us a way forward to 3.0, which will
> allow us to make rapid and significant improvements in functionality,
> usability, quality, scalability and ease of development. Some of the
> 2.6 items may need a bit more time and, therefore, we may want to
> extend code freeze by a few weeks.
>
> A number of those involved in the conversations so far are willing and
> able to provide resources to execute against these plans. But we need
> more participation, certainly. The Sakai Foundation is able to offer
> UX leadership, project management support and quality assurance/
> documentation help.
>
> So...take a look. Make your comments. And let me know if you have
> resources (people or otherwise) that could help. This is a crucial
> time to get started on 3.0 and we definitely need additional resource.
> This is not just developer help...we need design, documentation, QA
> and project management.
>
> Best regards,
>
> Michael
>
> --
> Michael Korcuska
> Executive Director, Sakai Foundation
> mkorcuska@...
> mobile: [phone] // phone: [phone]
> skype: mkorcuska
>
>
>
> --
> Michael Korcuska
> Executive Director, Sakai Foundation
> mkorcuska@...
> mobile: [phone] // phone: [phone]
> skype: mkorcuska
>
>
> ________________________________
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a.
> sakai-dev) site.
> You can modify how you receive notifications at My Workspace > Preferences.
>
>
> ________________________________
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org//portal) from the Project: Portfolio site.
> You can modify how you receive notifications at My Workspace > Preferences.
>

--
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
[phone]
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the Project: Portfolio site.
You can modify how you receive notifications at My Workspace > Preferences.

[Nathan Pearson-2]

Regrettably, I've missed the manager meetings I most wanted to be a part of,
so forgive me if I'm duplicating a topic that's already been discussed.

I'm wondering if we might benefit from a secondary track that develops an
"organizational roadmap" which feeds into the product roadmap.

Almost everyone I speak with offers ideas (often in the form of gripes)
about how we as a community can be more efficient.  I have a few ideas of my
own, as I'm sure many of you on these lists do.  Since the way we work is so
tightly coupled with what we end up producing, it might be nice to spend
some focused attention on distilling organizational milestones that are
required for the successful execution of any product roadmap.

The reason I'm thinking it might be good to keep this as a separate, but
related discussion, is simply due to the depth of each domain.  As it stands
today, I find we commonly make organizational assumptions (or even ignore
lack of organization) when discussing product plans, which leads to rude
awakenings later on.  By having a defined forum for discussing "how" that
separates our discussion from "what", we might stand a chance of avoiding
those unexpected surprises -- plus, our product roadmap would likely be more
productive since we'd be working with realistic expectations.

Nathan




On Mon, Aug 4, 2008 at 2:31 PM, Clay Fenlason
<clay.fenlason@...>wrote:

> It's a just concern, and one reflected in both the discussions and the
> document. It's for that reason that there's been a push for the
> Foundation to provide project management coordination to make sure
> we're taking on a scope which can be delivered. Not every loose end
> is tied, and some recruitment is still necessary, but enough
> committments have been made that it seems no longer outrageous to
> think that the plan (in rough outline) could be within reach.
>
> There seem to be two simple ways to advance the product: the first is
> to let everyone scratch their own itch and see what emerges; the
> second is to articulate a unifying vision and rally people to the
> banner. Granted that neither will work for us (if they work for
> anybody) in those distilled forms, we nevertheless have a history of
> tilting toward the former, and we've evinced a real difficulty doing
> anything like creating a roadmap, for example, or constructing a
> collaboration with more sophistication than the bilateral. I've been
> much encouraged by the beginning of these manager discussions to the
> extent that they recognize that there are classes of problems that
> call for more coordination, and they are critical for our future.
>
> I have at times thought that our resource problems are as much matters
> of coordination as questions of supply. We waste energy on cures
> rather than prevention, we don't give enough thought to how our
> variegated issues are facets of a shared problem, we allow our choices
> to deepen a reliance on a particular skillset (the Java architect
> steeped in novel Sakai idioms), or we are too short-sighted about
> design - both UX and technical. If I prize this emerging roadmap it's
> not for the details of its product vision (though I prize also that)
> but because it signals to me a new level of maturity for our
> collaboration - if it goes somewhere. Our ability to agree and
> execute upon a plan in this way seems to me really crucial.
>
> So I think the resource question is central to the roadmap adumbrated
> in the document, both in what it hopes to achieve (since many of the
> hoped-for benefits include expanding our pool of available resource
> and reducing burdens on existing resource) and what we need to get
> there.
>
> ~Clay
>
> On Mon, Aug 4, 2008 at 3:42 PM, Charles Hedrick <hedrick@...>
> wrote:
> > This is a neat idea. However I have one major concern: One historical
> > problem with quality in Sakai has been due to insufficient resources. I'd
>
> > rather have a stodgy user interface that is well implemented than a
> snazzy
> > one where there's wasn't enough staff time to get everything working
> > properly. I'd like to make sure that there are really sufficient
> commitments
> > before proceeding down this path.
> >
> > On Aug 4, 2008, at 1:59 PM, Michael Korcuska wrote:
> >
> > Greetings,
> >
> > In the weeks before, during and since Paris, a group of managers
> > planning to commit staff time to the next set of releases have been
> > discussing common interests and potential goals. These conversations
> > have grappled with a number of important issues including new user
> > interface metaphors, a new and simpler kernel, replacement of some
> > custom code with free open source alternatives and the place of social
> > networking inside a learning/collaboration platform. Along the way,
> > the group also discussed what it would like to have in the next
> > release--a reflection that while it is important to talk about a big
> > change we should also be focused on what is immediately in front of us.
> >
> > So, it's time to get the results of this discussion published and get
> > everyone involved. The following wiki page explains the ideas that
> > have been discussed:
> >
> > http://confluence.sakaiproject.org/confluence/x/VQAjAg
> >
> > I've been involved in all of these discussions and feel that the plans
> > outlined bring important and significant value to the 2.6 release
> > while, at the same time, giving us a way forward to 3.0, which will
> > allow us to make rapid and significant improvements in functionality,
> > usability, quality, scalability and ease of development. Some of the
> > 2.6 items may need a bit more time and, therefore, we may want to
> > extend code freeze by a few weeks.
> >
> > A number of those involved in the conversations so far are willing and
> > able to provide resources to execute against these plans. But we need
> > more participation, certainly. The Sakai Foundation is able to offer
> > UX leadership, project management support and quality assurance/
> > documentation help.
> >
> > So...take a look. Make your comments. And let me know if you have
> > resources (people or otherwise) that could help. This is a crucial
> > time to get started on 3.0 and we definitely need additional resource.
> > This is not just developer help...we need design, documentation, QA
> > and project management.
> >
> > Best regards,
> >
> > Michael
> >
> > --
> > Michael Korcuska
> > Executive Director, Sakai Foundation
> > mkorcuska@...
> > mobile: [phone] // phone: [phone]
> > skype: mkorcuska
> >
> >
> >
> > --
> > Michael Korcuska
> > Executive Director, Sakai Foundation
> > mkorcuska@...
> > mobile: [phone] // phone: [phone]
> > skype: mkorcuska
> >
> >
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the DG: Development
> (a.k.a.
> > sakai-dev) site.
> > You can modify how you receive notifications at My Workspace >
> Preferences.
> >
> >
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the Project: Portfolio
> site.
> > You can modify how you receive notifications at My Workspace >
> Preferences.
> >
>
>
>
> --
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> [phone]
> ------------------------------
>
> This automatic notification message was sent by Sakai Collab (
> https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a.
> sakai-dev) site.
> You can modify how you receive notifications at My Workspace > Preferences.
>

--
Nathan Pearson | UX Lead | Sakai Foundation

E. me@...
M. 602.418.5092
Y. npearson99 (Yahoo)
S. npearson99 (Skype)

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[John Norman]

I don't have time to get into this, but a relevant discussion here is  
how we organise to do R&D and then how R&D projects move into  
production.

We seem to tend to limit ourselves to problem -> solution ->  
implementation.

I would like to see more problem/opportunity -> analysis/brainstorming  
-> prototyping (more than one) -> user feedback -> refinement of goals  
and prototype -> business review (how important to how many campuses) -
 > production integration planning (includes QA, accessibility,  
internationalisation, etc.) -> roadmap -> implementation.

An off-the-wall example might be "why do we limit ourselves to  
creating groups as site members?" I don't know if that is important or  
not, but I don't think we have a good way of discussing such ideas  
cross-institutionally, if someone did create a prototype, it would  
probably be analysed by the rest of the community as production code  
and either rejected (risk-benefit too low) or embraced prematurely  
because the benefit is so attractive it appears to outweigh the  
(probably underestimated) risk. (or maybe left to languish in contrib  
until the original author has brought it up to standard and  
persuasively demonstrated the benefits).

John

On 5 Aug 2008, at 03:40, Nathan Pearson wrote:

> Regrettably, I've missed the manager meetings I most wanted to be a  
> part of, so forgive me if I'm duplicating a topic that's already  
> been discussed.
>
> I'm wondering if we might benefit from a secondary track that  
> develops an "organizational roadmap" which feeds into the product  
> roadmap.
>
> Almost everyone I speak with offers ideas (often in the form of  
> gripes) about how we as a community can be more efficient.  I have a  
> few ideas of my own, as I'm sure many of you on these lists do.  
> Since the way we work is so tightly coupled with what we end up  
> producing, it might be nice to spend some focused attention on  
> distilling organizational milestones that are required for the  
> successful execution of any product roadmap.
>
> The reason I'm thinking it might be good to keep this as a separate,  
> but related discussion, is simply due to the depth of each domain.  
> As it stands today, I find we commonly make organizational  
> assumptions (or even ignore lack of organization) when discussing  
> product plans, which leads to rude awakenings later on.  By having a  
> defined forum for discussing "how" that separates our discussion  
> from "what", we might stand a chance of avoiding those unexpected  
> surprises -- plus, our product roadmap would likely be more  
> productive since we'd be working with realistic expectations.
>
> Nathan
>
>
>
>
> On Mon, Aug 4, 2008 at 2:31 PM, Clay Fenlason <clay.fenlason@...
> > wrote:
> It's a just concern, and one reflected in both the discussions and the
> document. It's for that reason that there's been a push for the
> Foundation to provide project management coordination to make sure
> we're taking on a scope which can be delivered. Not every loose end
> is tied, and some recruitment is still necessary, but enough
> committments have been made that it seems no longer outrageous to
> think that the plan (in rough outline) could be within reach.
>
> There seem to be two simple ways to advance the product: the first is
> to let everyone scratch their own itch and see what emerges; the
> second is to articulate a unifying vision and rally people to the
> banner. Granted that neither will work for us (if they work for
> anybody) in those distilled forms, we nevertheless have a history of
> tilting toward the former, and we've evinced a real difficulty doing
> anything like creating a roadmap, for example, or constructing a
> collaboration with more sophistication than the bilateral. I've been
> much encouraged by the beginning of these manager discussions to the
> extent that they recognize that there are classes of problems that
> call for more coordination, and they are critical for our future.
>
> I have at times thought that our resource problems are as much matters
> of coordination as questions of supply. We waste energy on cures
> rather than prevention, we don't give enough thought to how our
> variegated issues are facets of a shared problem, we allow our choices
> to deepen a reliance on a particular skillset (the Java architect
> steeped in novel Sakai idioms), or we are too short-sighted about
> design - both UX and technical. If I prize this emerging roadmap it's
> not for the details of its product vision (though I prize also that)
> but because it signals to me a new level of maturity for our
> collaboration - if it goes somewhere. Our ability to agree and
> execute upon a plan in this way seems to me really crucial.
>
> So I think the resource question is central to the roadmap adumbrated
> in the document, both in what it hopes to achieve (since many of the
> hoped-for benefits include expanding our pool of available resource
> and reducing burdens on existing resource) and what we need to get
> there.
>
> ~Clay
>
> On Mon, Aug 4, 2008 at 3:42 PM, Charles Hedrick  
> <hedrick@...> wrote:
> > This is a neat idea. However I have one major concern: One  
> historical
> > problem with quality in Sakai has been due to insufficient  
> resources. I'd
> > rather have a stodgy user interface that is well implemented than  
> a snazzy
> > one where there's wasn't enough staff time to get everything working
> > properly. I'd like to make sure that there are really sufficient  
> commitments
> > before proceeding down this path.
> >
> > On Aug 4, 2008, at 1:59 PM, Michael Korcuska wrote:
> >
> > Greetings,
> >
> > In the weeks before, during and since Paris, a group of managers
> > planning to commit staff time to the next set of releases have been
> > discussing common interests and potential goals. These conversations
> > have grappled with a number of important issues including new user
> > interface metaphors, a new and simpler kernel, replacement of some
> > custom code with free open source alternatives and the place of  
> social
> > networking inside a learning/collaboration platform. Along the way,
> > the group also discussed what it would like to have in the next
> > release--a reflection that while it is important to talk about a big
> > change we should also be focused on what is immediately in front  
> of us.
> >
> > So, it's time to get the results of this discussion published and  
> get
> > everyone involved. The following wiki page explains the ideas that
> > have been discussed:
> >
> > http://confluence.sakaiproject.org/confluence/x/VQAjAg
> >
> > I've been involved in all of these discussions and feel that the  
> plans
> > outlined bring important and significant value to the 2.6 release
> > while, at the same time, giving us a way forward to 3.0, which will
> > allow us to make rapid and significant improvements in  
> functionality,
> > usability, quality, scalability and ease of development. Some of the
> > 2.6 items may need a bit more time and, therefore, we may want to
> > extend code freeze by a few weeks.
> >
> > A number of those involved in the conversations so far are willing  
> and
> > able to provide resources to execute against these plans. But we  
> need
> > more participation, certainly. The Sakai Foundation is able to offer
> > UX leadership, project management support and quality assurance/
> > documentation help.
> >
> > So...take a look. Make your comments. And let me know if you have
> > resources (people or otherwise) that could help. This is a crucial
> > time to get started on 3.0 and we definitely need additional  
> resource.
> > This is not just developer help...we need design, documentation, QA
> > and project management.
> >
> > Best regards,
> >
> > Michael
> >
> > --
> > Michael Korcuska
> > Executive Director, Sakai Foundation
> > mkorcuska@...
> > mobile: [phone] // phone: [phone]
> > skype: mkorcuska
> >
> >
> >
> > --
> > Michael Korcuska
> > Executive Director, Sakai Foundation
> > mkorcuska@...
> > mobile: [phone] // phone: [phone]
> > skype: mkorcuska
> >
> >
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the DG: Development  
> (a.k.a.
> > sakai-dev) site.
> > You can modify how you receive notifications at My Workspace >  
> Preferences.
> >
> >
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the Project:  
> Portfolio site.
> > You can modify how you receive notifications at My Workspace >  
> Preferences.
> >
>
>
>
> --
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> [phone]
>
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the DG: Development (a.k.a. sakai-dev) site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. me@...
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the DG: Development (a.k.a. sakai-dev) site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Teaching & Learning site.
You can modify how you receive notifications at My Workspace > Preferences.

[Nathan Pearson-2]

That's exactly the stuff I was thinking about.  Also in my mind are
questions related to how the product is managed.  For example, what is the
core.. and what is everything else?  Should the core be as large and mired
with release challenges as it is today -- or should the core be lighter?
Should tools/widgets/chunks of functionality only be part of the core if
they have a dedicated team behind them?

Basically, we're moving into a new era of product vision, design, and
development... it stands to reason that we should also do an inventory of
our operations.



Sorry to have hijacked your initial thread Michael.

On Tue, Aug 5, 2008 at 1:17 AM, John Norman <john@...> wrote:

> I don't have time to get into this, but a relevant discussion here is how
> we organise to do R&D and then how R&D projects move into production.
>
> We seem to tend to limit ourselves to problem -> solution ->
> implementation.
>
> I would like to see more problem/opportunity -> analysis/brainstorming ->
> prototyping (more than one) -> user feedback -> refinement of goals and
> prototype -> business review (how important to how many campuses) ->
> production integration planning (includes QA, accessibility,
> internationalisation, etc.) -> roadmap -> implementation.
>
> An off-the-wall example might be "why do we limit ourselves to creating
> groups as site members?" I don't know if that is important or not, but I
> don't think we have a good way of discussing such ideas
> cross-institutionally, if someone did create a prototype, it would probably
> be analysed by the rest of the community as production code and either
> rejected (risk-benefit too low) or embraced prematurely because the benefit
> is so attractive it appears to outweigh the (probably underestimated) risk.
> (or maybe left to languish in contrib until the original author has brought
> it up to standard and persuasively demonstrated the benefits).
>
> John
>
> On 5 Aug 2008, at 03:40, Nathan Pearson wrote:
>
>  Regrettably, I've missed the manager meetings I most wanted to be a part
>> of, so forgive me if I'm duplicating a topic that's already been discussed.
>>
>> I'm wondering if we might benefit from a secondary track that develops an
>> "organizational roadmap" which feeds into the product roadmap.
>>
>> Almost everyone I speak with offers ideas (often in the form of gripes)
>> about how we as a community can be more efficient.  I have a few ideas of my
>> own, as I'm sure many of you on these lists do.  Since the way we work is so
>> tightly coupled with what we end up producing, it might be nice to spend
>> some focused attention on distilling organizational milestones that are
>> required for the successful execution of any product roadmap.
>>
>> The reason I'm thinking it might be good to keep this as a separate, but
>> related discussion, is simply due to the depth of each domain.  As it stands
>> today, I find we commonly make organizational assumptions (or even ignore
>> lack of organization) when discussing product plans, which leads to rude
>> awakenings later on.  By having a defined forum for discussing "how" that
>> separates our discussion from "what", we might stand a chance of avoiding
>> those unexpected surprises -- plus, our product roadmap would likely be more
>> productive since we'd be working with realistic expectations.
>>
>> Nathan
>>
>>
>>
>>
>> On Mon, Aug 4, 2008 at 2:31 PM, Clay Fenlason <
>> clay.fenlason@...> wrote:
>> It's a just concern, and one reflected in both the discussions and the
>> document. It's for that reason that there's been a push for the
>> Foundation to provide project management coordination to make sure
>> we're taking on a scope which can be delivered. Not every loose end
>> is tied, and some recruitment is still necessary, but enough
>> committments have been made that it seems no longer outrageous to
>> think that the plan (in rough outline) could be within reach.
>>
>> There seem to be two simple ways to advance the product: the first is
>> to let everyone scratch their own itch and see what emerges; the
>> second is to articulate a unifying vision and rally people to the
>> banner. Granted that neither will work for us (if they work for
>> anybody) in those distilled forms, we nevertheless have a history of
>> tilting toward the former, and we've evinced a real difficulty doing
>> anything like creating a roadmap, for example, or constructing a
>> collaboration with more sophistication than the bilateral. I've been
>> much encouraged by the beginning of these manager discussions to the
>> extent that they recognize that there are classes of problems that
>> call for more coordination, and they are critical for our future.
>>
>> I have at times thought that our resource problems are as much matters
>> of coordination as questions of supply. We waste energy on cures
>> rather than prevention, we don't give enough thought to how our
>> variegated issues are facets of a shared problem, we allow our choices
>> to deepen a reliance on a particular skillset (the Java architect
>> steeped in novel Sakai idioms), or we are too short-sighted about
>> design - both UX and technical. If I prize this emerging roadmap it's
>> not for the details of its product vision (though I prize also that)
>> but because it signals to me a new level of maturity for our
>> collaboration - if it goes somewhere. Our ability to agree and
>> execute upon a plan in this way seems to me really crucial.
>>
>> So I think the resource question is central to the roadmap adumbrated
>> in the document, both in what it hopes to achieve (since many of the
>> hoped-for benefits include expanding our pool of available resource
>> and reducing burdens on existing resource) and what we need to get
>> there.
>>
>> ~Clay
>>
>> On Mon, Aug 4, 2008 at 3:42 PM, Charles Hedrick <hedrick@...>
>> wrote:
>> > This is a neat idea. However I have one major concern: One historical
>> > problem with quality in Sakai has been due to insufficient resources.
>> I'd
>> > rather have a stodgy user interface that is well implemented than a
>> snazzy
>> > one where there's wasn't enough staff time to get everything working
>> > properly. I'd like to make sure that there are really sufficient
>> commitments
>> > before proceeding down this path.
>> >
>> > On Aug 4, 2008, at 1:59 PM, Michael Korcuska wrote:
>> >
>> > Greetings,
>> >
>> > In the weeks before, during and since Paris, a group of managers
>> > planning to commit staff time to the next set of releases have been
>> > discussing common interests and potential goals. These conversations
>> > have grappled with a number of important issues including new user
>> > interface metaphors, a new and simpler kernel, replacement of some
>> > custom code with free open source alternatives and the place of social
>> > networking inside a learning/collaboration platform. Along the way,
>> > the group also discussed what it would like to have in the next
>> > release--a reflection that while it is important to talk about a big
>> > change we should also be focused on what is immediately in front of us.
>> >
>> > So, it's time to get the results of this discussion published and get
>> > everyone involved. The following wiki page explains the ideas that
>> > have been discussed:
>> >
>> > http://confluence.sakaiproject.org/confluence/x/VQAjAg
>> >
>> > I've been involved in all of these discussions and feel that the plans
>> > outlined bring important and significant value to the 2.6 release
>> > while, at the same time, giving us a way forward to 3.0, which will
>> > allow us to make rapid and significant improvements in functionality,
>> > usability, quality, scalability and ease of development. Some of the
>> > 2.6 items may need a bit more time and, therefore, we may want to
>> > extend code freeze by a few weeks.
>> >
>> > A number of those involved in the conversations so far are willing and
>> > able to provide resources to execute against these plans. But we need
>> > more participation, certainly. The Sakai Foundation is able to offer
>> > UX leadership, project management support and quality assurance/
>> > documentation help.
>> >
>> > So...take a look. Make your comments. And let me know if you have
>> > resources (people or otherwise) that could help. This is a crucial
>> > time to get started on 3.0 and we definitely need additional resource.
>> > This is not just developer help...we need design, documentation, QA
>> > and project management.
>> >
>> > Best regards,
>> >
>> > Michael
>> >
>> > --
>> > Michael Korcuska
>> > Executive Director, Sakai Foundation
>> > mkorcuska@...
>> > mobile: [phone] // phone: [phone]
>> > skype: mkorcuska
>> >
>> >
>> >
>> > --
>> > Michael Korcuska
>> > Executive Director, Sakai Foundation
>> > mkorcuska@...
>> > mobile: [phone] // phone: [phone]
>> > skype: mkorcuska
>> >
>> >
>> > ________________________________
>> > This automatic notification message was sent by Sakai Collab
>> > (https://collab.sakaiproject.org//portal) from the DG: Development
>> (a.k.a.
>> > sakai-dev) site.
>> > You can modify how you receive notifications at My Workspace >
>> Preferences.
>> >
>> >
>> > ________________________________
>> > This automatic notification message was sent by Sakai Collab
>> > (https://collab.sakaiproject.org//portal) from the Project: Portfolio
>> site.
>> > You can modify how you receive notifications at My Workspace >
>> Preferences.
>> >
>>
>>
>>
>> --
>> Clay Fenlason
>> Director, Educational Technology
>> Georgia Institute of Technology
>> [phone]
>>
>>
>> This automatic notification message was sent by Sakai Collab (
>> https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a.
>> sakai-dev) site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>>
>>
>> --
>> Nathan Pearson | UX Lead | Sakai Foundation
>>
>> E. me@...
>> M. 602.418.5092
>> Y. npearson99 (Yahoo)
>> S. npearson99 (Skype)
>>
>>
>> This automatic notification message was sent by Sakai Collab (
>> https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a.
>> sakai-dev) site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>
>

--
Nathan Pearson | UX Lead | Sakai Foundation

E. me@...
M. 602.418.5092
Y. npearson99 (Yahoo)
S. npearson99 (Skype)

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[Mark Norton]

Clay Fenlason wrote:
> So I think the resource question is central to the roadmap
Speaking rhetorically:  Why would anyone want to work on Sakai?  Think
about it.  It's a bloated morass of java code written in a dozen or more
styles with no overriding standards, poor (and scattered) documentation,
an architecture that works well in some areas and is pretty much broken
in others, etc.  The learning curve is significant towards creating even
the simplest tool.  Even setting up a development environment is an
advanced task.  If you get past all that, your work is likely to
language in a branch or patch and never see the light of day.  Heck, it
isn't even clear who to talk to, since committers are largely unknown.

Many of the people who work on Sakai do so because they are directed to
by the IT organization in their university.  It may be possible to
expand that base, but not by a lot, I suspect.  The universities that
can apply resources to Sakai probably already are.  My question is:  how
can we change how we operate to make existing participants WANT to
contribute more?  More importantly:  how can we improve our processes
such that developers who control their own time might want to
participate in Sakai development.

Lest I sound too negative here, I freely acknowledge that the project
has made SIGNIFICANT improvements over the past few years and this trend
continues in a positive direction (I believe).  That said, let's explore
the lifecycle for a minute (or 10) and see if we can isolate some pain
points.  I'm going to focus on the independent developer case, in part
because it is the more challenging one.

At four years into the project, Sakai is widely known in the educational
community.  There was a lot of buzz and interest initially and while
that has settled down quite a bit, we still make the news from time to
time.  Suppose I am an experienced Java developer, perhaps in a
university setting, with time that I am allowed to use at my own
discretion.  I am removing the funding part of the equation to focus on
other aspects, though funding is a part of the larger problem, too.  So
read a reference to Sakai in the Chronicles (etc) and I'm interested.  
How do I find out about Sakai?

The obvious place to start is http://www.sakaiproject.org.  (Feeling
lucky on Google will bring you right there).  There's lots of good news
here.  Anthony has done a great job of pulling together a lot of the
links needed to find things right on the home page of the web site.  I
can find most of what I need to get started from here.  Sadly (and this
is no criticism of Anthony), I also notice that the site is already
pretty dated.  The last newsletter is for July 26th -- I wonder if there
have been any since then?  The 9th Sakai conference is listed as an
upcoming event.  Etc.  First impressions are important.  Our web site
needs to be up to date at least to the current week.

If I have never experienced Sakai before, I might want to poke around a
bit.  Fortunately, there places I can do that.  Both Unicon and rSmart
have test drive sites and there is another one called SakaisTheLimit
(which, somehow, I have never heard of).  All of these do a find job of
dipping a toe into the Sakai waters (though sharks lurk below).  
Interestingly, there is no link to collab.sakaiproject.org on the home
page of www.sakaiproject.org.  Perhaps it is a bit difficult to explain
what that site is for.  Hmm - what is it for?  (We need to re-think what
collab is used for.)

In the interests of brevitiy (ha!), let's assume that I (as a developer)
decide to poke around the code a bit and maybe set up a development
environment.  More good news/bad news.  The good is that Aaron Z. has
done an outstanding job of describing how to set up the Sakai
development environment.  Further, it is kept up to date with the latest
release of Sakai (big rep points there).  Following the instructions, I
get my first glimpse into the complexity of Sakai.  Depending on how
good my developer skills are, I can get the basic environment set up and
running in a few hours.  Less skilled developers will probably take a
day or more and the odds of them getting it right are not good (as
documented in any number of sakai-dev messages).  This is another pain
point that we could improve -- streamlining and simplifying setup of a
development environment.

So let's assume that I'm pretty familiar with setting up java web
application development environments and databases.  Following Aaron's
instructions, I get a working Sakai environment.  Building and deploying
Sakai can take an hour or more, depending on how fast your computer is
(K1 will speed this up some).  That's frustrating, but unless me (as the
new developer) understands that there is a stripped down version of
Sakai (Cafe), I'm likely to build the whole shebang and that takes a
fair bit of time.

Regardless, I'm into the code now.  Train wreck time.  How the heck am I
supposed to figure out how to write an application, even something as
simple as "Hello World" by looking at the code base?  There are answers
to this question in the Programmer's Cafe and Sakaipedia (admittedly out
of date, mea culpa), but how does a newbie (even an experienced one)
find that answer.  Documentation is getting better, but our organization
of it is still horrible.  This gets worse once I start digging down into
confluence.  Which pages are the "official" documents?  Worse still once
I start looking at code - six ways to do even simple things.  There are
many examples of Sakai code (including in the Framework) that would
(frankly) disgust me.  The use of public inner classes, for example.  I
quickly come up against the lack of standards as well.  Which
presentation technology should I use?  Should I code my application as a
server-side one or client-side?  There are many, many reasons for why
things are the way they are, but I believe the state of Sakai code is
one of the biggest turn-offs to developing for it.  We need more
tutorials, better documentation, better organization for documentation,
and enforced coding standards.

Clearly these guys need my help badly (otherwise, I am out of here).  
I've got some time, so lets work on something.  The first question is:  
what?  What work needs doing in Sakai.  Sure, I could figure out Jira
and tackle one of the 2871 open issues (today's count), but I know
almost nothing about Sakai.  Further, I don't know anyone in Sakai or
what the processes are (again, buried documentation).  By this time, I'm
several days into coming up to speed on Sakai and it's getting a bit
frustrating.  Aha!  I've discovered something that needs doing:  there
is no utility to manage the creating of academic sessions (long story
behind this that will be dropped to avoid in-box size limits).  A simple
tool that CLEARLY is needed.  I've done JSP work before, so I code the
tool as JavaServer Pages (not the best choice, but how am I to figure
out what is best?).  Getting it to work was a real chore, but I managed
to find a couple of examples in contrib that let me figure out how to
configure web.xml and get it recognized as a Sakai tool.  Yeah, I did
write it using JDBC instead of Hibernate (lack of standards, again), but
I did add support for Hypersonic, MySQL, and Oracle - I even tested it
(manually).  It all works just fine.  So, with great pride, I announce
the completion of this work on sakai-dev and attach the code as a ZIP
archive.

What sort of reaction do you think I'd get?  The kindest reaction would
be a patient explanation (from four different people) that Sakai has a
process by which tools are written.  You need to have a Jira entry.  You
need to propose it to the community first.  You should check it into
contrib.  Sadly, we can't include in the next build of Sakai (in spite
of the desperate need), because it is only a contrib tool and needs to
be carefully evaluated and used by several universities first.  At this
point, we lose our new developer.  It's not that our processes are bad -
they are designed to ensure the best possible quality applications we
can manage.  It's that they set newbies up for failure.  Even if he did
follow the recommended procedures, chances are it would be stuck in
contrib for a year or more.  Our new developer is unlikely to see that
this doesn't really matter as much as it appears, since a truly useful
tool will get used, even from contrib and it will migrate into the
release over time.

The simple fact is that we have not rewarded independent initiative.  
This happens over and over on large and small scales.  To me, this is
the main reason why we don't retain good (or even fair) developers.  If
they make it past the learning curve, there isn't enough reward.  It's
open source!  If I'm not getting paid to do it or I have the choice on
how to spend my time, what is the return to me? (Interested readers are
urged to read Eric Raymond's book available from Amazon at,
*http://tinyurl.com/5scnac)*

We (as a community) need to think hard about how we support and reward
contributors.  I'm not just talking about Sakai Fellowships, TWSIA
awards, or even grants.  I thinking about feel good responses,
ego-boosting, or even simple thanks.  Just a feeling that, somehow, the
rest of the world (Sakai in this case) appreciates the fact that someone
spend hours working on a contribution to Sakai rather than play a video
game.  BTW, this extends to ALL contributors, not just programmers.  I
include teachers who write up new pedagaogy practices, UI designers,
accessibility specialists, QA testers, a CIO who shares the slides she
wrote to pitch Sakai, etc.  Somehow, we need need to find a way to make
people WANT to work on Sakai.

- Mark Norton





----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Teaching & Learning site.
You can modify how you receive notifications at My Workspace > Preferences.

[John Norman]

Mark

You raise a lot of issues here, many of which are close to my heart  
but not all of which are in my power (alone) to affect. However, I  
think there are some things going on that will significantly improve  
the situation. At the hackathon, Clay hit on the idea of a Foundation-
hosted JSON/XML server so a developer wanting to use *existing  
services* can just start coding an interface in Javascript that mashes  
up Sakai information in new ways, this of course depends on good  
documentation of those data services and I am trying to find ways of  
ensuring we create and maintain that documentation. I *hope* that K2  
will advance the back-end and that we will continue to make progress  
on back-end services, testing, etc. With the "manager group" we are  
feeling our way forward to greater collaboration and cooperation among  
institutional resources, which I hope will help make the space more  
attractive to individual developers (we will need to document more if  
we are to collaborate effectively at a distance).

But we could all do more to recognise and reward respective efforts.  
For me one of the big boosts was the 'Teaching with Sakai' award  
winner presentations at the conference. I highly recommend the video  
to anyone who needs cheering up or wants to here a thank-you from the  
people we are trying to help.

rtsp://video.cpm.jussieu.fr/Archive/visio/sakai/ad080702_1.rmvb

John

PS having a Flash version prominent on the Sakai site would be a great  
thing (with appropriate credits to our hosts UPMC of course)

On 5 Aug 2008, at 16:52, Mark Norton wrote:

>
> Clay Fenlason wrote:
>> So I think the resource question is central to the roadmap
> Speaking rhetorically:  Why would anyone want to work on Sakai?  Think
> about it.  It's a bloated morass of java code written in a dozen or  
> more
> styles with no overriding standards, poor (and scattered)  
> documentation,
> an architecture that works well in some areas and is pretty much  
> broken
> in others, etc.  The learning curve is significant towards creating  
> even
> the simplest tool.  Even setting up a development environment is an
> advanced task.  If you get past all that, your work is likely to
> language in a branch or patch and never see the light of day.  Heck,  
> it
> isn't even clear who to talk to, since committers are largely unknown.
>
> Many of the people who work on Sakai do so because they are directed  
> to
> by the IT organization in their university.  It may be possible to
> expand that base, but not by a lot, I suspect.  The universities that
> can apply resources to Sakai probably already are.  My question is:  
> how
> can we change how we operate to make existing participants WANT to
> contribute more?  More importantly:  how can we improve our processes
> such that developers who control their own time might want to
> participate in Sakai development.
>
> Lest I sound too negative here, I freely acknowledge that the project
> has made SIGNIFICANT improvements over the past few years and this  
> trend
> continues in a positive direction (I believe).  That said, let's  
> explore
> the lifecycle for a minute (or 10) and see if we can isolate some pain
> points.  I'm going to focus on the independent developer case, in part
> because it is the more challenging one.
>
> At four years into the project, Sakai is widely known in the  
> educational
> community.  There was a lot of buzz and interest initially and while
> that has settled down quite a bit, we still make the news from time to
> time.  Suppose I am an experienced Java developer, perhaps in a
> university setting, with time that I am allowed to use at my own
> discretion.  I am removing the funding part of the equation to focus  
> on
> other aspects, though funding is a part of the larger problem, too.  
> So
> read a reference to Sakai in the Chronicles (etc) and I'm interested.
> How do I find out about Sakai?
>
> The obvious place to start is http://www.sakaiproject.org.  (Feeling
> lucky on Google will bring you right there).  There's lots of good  
> news
> here.  Anthony has done a great job of pulling together a lot of the
> links needed to find things right on the home page of the web site.  I
> can find most of what I need to get started from here.  Sadly (and  
> this
> is no criticism of Anthony), I also notice that the site is already
> pretty dated.  The last newsletter is for July 26th -- I wonder if  
> there
> have been any since then?  The 9th Sakai conference is listed as an
> upcoming event.  Etc.  First impressions are important.  Our web site
> needs to be up to date at least to the current week.
>
> If I have never experienced Sakai before, I might want to poke  
> around a
> bit.  Fortunately, there places I can do that.  Both Unicon and rSmart
> have test drive sites and there is another one called SakaisTheLimit
> (which, somehow, I have never heard of).  All of these do a find job  
> of
> dipping a toe into the Sakai waters (though sharks lurk below).
> Interestingly, there is no link to collab.sakaiproject.org on the home
> page of www.sakaiproject.org.  Perhaps it is a bit difficult to  
> explain
> what that site is for.  Hmm - what is it for?  (We need to re-think  
> what
> collab is used for.)
>
> In the interests of brevitiy (ha!), let's assume that I (as a  
> developer)
> decide to poke around the code a bit and maybe set up a development
> environment.  More good news/bad news.  The good is that Aaron Z. has
> done an outstanding job of describing how to set up the Sakai
> development environment.  Further, it is kept up to date with the  
> latest
> release of Sakai (big rep points there).  Following the  
> instructions, I
> get my first glimpse into the complexity of Sakai.  Depending on how
> good my developer skills are, I can get the basic environment set up  
> and
> running in a few hours.  Less skilled developers will probably take a
> day or more and the odds of them getting it right are not good (as
> documented in any number of sakai-dev messages).  This is another pain
> point that we could improve -- streamlining and simplifying setup of a
> development environment.
>
> So let's assume that I'm pretty familiar with setting up java web
> application development environments and databases.  Following Aaron's
> instructions, I get a working Sakai environment.  Building and  
> deploying
> Sakai can take an hour or more, depending on how fast your computer is
> (K1 will speed this up some).  That's frustrating, but unless me (as  
> the
> new developer) understands that there is a stripped down version of
> Sakai (Cafe), I'm likely to build the whole shebang and that takes a
> fair bit of time.
>
> Regardless, I'm into the code now.  Train wreck time.  How the heck  
> am I
> supposed to figure out how to write an application, even something as
> simple as "Hello World" by looking at the code base?  There are  
> answers
> to this question in the Programmer's Cafe and Sakaipedia (admittedly  
> out
> of date, mea culpa), but how does a newbie (even an experienced one)
> find that answer.  Documentation is getting better, but our  
> organization
> of it is still horrible.  This gets worse once I start digging down  
> into
> confluence.  Which pages are the "official" documents?  Worse still  
> once
> I start looking at code - six ways to do even simple things.  There  
> are
> many examples of Sakai code (including in the Framework) that would
> (frankly) disgust me.  The use of public inner classes, for  
> example.  I
> quickly come up against the lack of standards as well.  Which
> presentation technology should I use?  Should I code my application  
> as a
> server-side one or client-side?  There are many, many reasons for why
> things are the way they are, but I believe the state of Sakai code is
> one of the biggest turn-offs to developing for it.  We need more
> tutorials, better documentation, better organization for  
> documentation,
> and enforced coding standards.
>
> Clearly these guys need my help badly (otherwise, I am out of here).
> I've got some time, so lets work on something.  The first question is:
> what?  What work needs doing in Sakai.  Sure, I could figure out Jira
> and tackle one of the 2871 open issues (today's count), but I know
> almost nothing about Sakai.  Further, I don't know anyone in Sakai or
> what the processes are (again, buried documentation).  By this time,  
> I'm
> several days into coming up to speed on Sakai and it's getting a bit
> frustrating.  Aha!  I've discovered something that needs doing:  there
> is no utility to manage the creating of academic sessions (long story
> behind this that will be dropped to avoid in-box size limits).  A  
> simple
> tool that CLEARLY is needed.  I've done JSP work before, so I code the
> tool as JavaServer Pages (not the best choice, but how am I to figure
> out what is best?).  Getting it to work was a real chore, but I  
> managed
> to find a couple of examples in contrib that let me figure out how to
> configure web.xml and get it recognized as a Sakai tool.  Yeah, I did
> write it using JDBC instead of Hibernate (lack of standards, again),  
> but
> I did add support for Hypersonic, MySQL, and Oracle - I even tested it
> (manually).  It all works just fine.  So, with great pride, I announce
> the completion of this work on sakai-dev and attach the code as a ZIP
> archive.
>
> What sort of reaction do you think I'd get?  The kindest reaction  
> would
> be a patient explanation (from four different people) that Sakai has a
> process by which tools are written.  You need to have a Jira entry.  
> You
> need to propose it to the community first.  You should check it into
> contrib.  Sadly, we can't include in the next build of Sakai (in spite
> of the desperate need), because it is only a contrib tool and needs to
> be carefully evaluated and used by several universities first.  At  
> this
> point, we lose our new developer.  It's not that our processes are  
> bad -
> they are designed to ensure the best possible quality applications we
> can manage.  It's that they set newbies up for failure.  Even if he  
> did
> follow the recommended procedures, chances are it would be stuck in
> contrib for a year or more.  Our new developer is unlikely to see that
> this doesn't really matter as much as it appears, since a truly useful
> tool will get used, even from contrib and it will migrate into the
> release over time.
>
> The simple fact is that we have not rewarded independent initiative.
> This happens over and over on large and small scales.  To me, this is
> the main reason why we don't retain good (or even fair) developers.  
> If
> they make it past the learning curve, there isn't enough reward.  It's
> open source!  If I'm not getting paid to do it or I have the choice on
> how to spend my time, what is the return to me? (Interested readers  
> are
> urged to read Eric Raymond's book available from Amazon at,
> *http://tinyurl.com/5scnac)*
>
> We (as a community) need to think hard about how we support and reward
> contributors.  I'm not just talking about Sakai Fellowships, TWSIA
> awards, or even grants.  I thinking about feel good responses,
> ego-boosting, or even simple thanks.  Just a feeling that, somehow,  
> the
> rest of the world (Sakai in this case) appreciates the fact that  
> someone
> spend hours working on a contribution to Sakai rather than play a  
> video
> game.  BTW, this extends to ALL contributors, not just programmers.  I
> include teachers who write up new pedagaogy practices, UI designers,
> accessibility specialists, QA testers, a CIO who shares the slides she
> wrote to pitch Sakai, etc.  Somehow, we need need to find a way to  
> make
> people WANT to work on Sakai.
>
> - Mark Norton
>
>
>
>
>
> ----------------------
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the DG: Development (a.k.a. sakai-dev) site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Teaching & Learning site.
You