Incubation in the uPortal ecosystem
25 views
Skip to first unread message
Andrew Petro
Jun 29, 2017, 3:53:23 PM6/29/17
to uPortal Developers
There are, concretely, today, a handful of microservice projects loosely associated with uPortal-home. uPortal-home is formally incubating. So these microservices-for-use-with (dependencies? sub-projects?), they're, well, doing what exactly, in terms of incubation? Also incubating as implied sub-modules of uPortal-home? Need to enter incubation separately? Need the uPortal project to spin up its own lightweight incubator and then incubate in that? Something else?
Background:
(This is the email list follow up on a couple of Pull Requests.)
More smaller relatively independent modules have some architectural advantages. Microservices and all that.
Modeling these more smaller relatively independent modules as separate GitHub repos also has some advantages, in making the tooling work better. Want to keep an eye on thing X and not thing Y? Then watch thing X and not thing Y.
The uPortal ecosystem should have more organisms. Oakland's lovely ReactJS-implemented course dashboard. Portal integrations for Edinburgh's enterprise notifications system. uPortal-home. A user profile application. Tools for academic advisors and students and course catelog user experiences and ....
And of course the uPortal ecosystem already has a slew of organisms. They're Portlets. And ResourceServer. And Maven plugins. And supporting utility libraries. And Soffit samples. And ... . We've long had a concept of grades of core-ness of Portlets associated with uPortal, with none of those going through separate formal Incubation processes. Which isn't to say that they couldn't benefit greatly from some of the attention to detail and projectness that incubation brings to bear. But it is to say that to date uPortal hasn't built out formal processes to incubate, to more formally model the status of, these little modules.
There are gains to be made in a bit more formality, a bit more care in characterizing these projects. Better characterizing the posture of the microservices came in part on the occasion of adding Christian Murphy as a uPortal-home committer. Does that imply committer status on these other projects as well? If it doesn't, well, then just how do those projects work, anyway?
Where I think this is going:
- We call these microservices uPortal Application Framework sub-projects out of pragmatism, so that they ride along with uPortal Home in its Incubation. Square them all away. Move them all over to a uPortal Project GitHub organization when we get there. This doesn't mean any less diligence about these -- they've gotta have licensing / markings / governance / everything all squared away to move. It does mean less blocking on inventing new uPortal project processes that do not currently exist.
- We note again that this is a problem space with lots of opportunities for improvement and spin up some volunteers and work to realize more of these opportunities. It should be clearer how portlets and Soffit producers and microservices come into the ecosystem, what the grades of degrees of being in the ecosystem are, who has committer status over what how. It should be clear how very welcoming and ready and eager we are to pull a ReactJS based course dashboard project (Hi Oakland colleagues!) into the ecosystem.
-Andrew
Andrew Petro
Jun 30, 2017, 9:23:28 AM6/30/17
to uPortal Developers
Reconsidering "We've long had a concept of grades of core-ness of Portlets associated with uPortal, with none of those going through separate formal Incubation processes."
I bet the history is more complicated than this. MyUW's hrs-portlets were in some kind of incubation at one point, for instance, with incubation failing for lack of engineering the portlets to be generally realizable. Jasig had an incubation process that predated Apereo's current incubation processes.
So it's probably more accurate to say some uPortal ecosystem components historically participated in incubation processes, but not in very recent history and not in the incubation process as reconstituted in Apereo.
Aaron Grant
Jun 30, 2017, 9:49:47 AM6/30/17
to Andrew Petro, uPortal Developers
Andrew,
I'd say 1-2 years ago the incubation group voted saying portlets would no longer need to be incubated and under uPortal Steering Committee's control. Prior to that many portlets were being incubated. This change I believe was made due to the lack of mentors at the time maybe 25% of all incubated projects were portlets.
Aaron
--
You received this message because you are subscribed to the Google Groups "uPortal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-dev+unsubscribe@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/uportal-dev/.
Andrew Petro
Jul 5, 2017, 12:27:53 PM7/5/17
to uPortal Developers
Noted the uPortal-home aspects of these incubation scope / process / practices / readiness questions in agenda for the July 12th 10a Eastern uPortal-home incubation check-in call.
Benito J. Gonzalez
Jul 5, 2017, 3:16:11 PM7/5/17
to uport...@apereo.org
Hi folks,
I agree with Aaron. There was some desire to move incubating portlets
and other small projects related to uPortal under uPortal Steering
Committee.
Notifications Portlet and Courses Portlet both went through JASIG
Incubation before the merger with Sakai. There were several portlets
other portlets as well.
My view is that microservices do not rise to the level of a project that
should be incubated. For these, we do not need additional adoption or
community. They should adhere to the practices of the parent project
(uPortal or uPortal-Home). Why were portlets even incubated?
I will be more precise. If the project is going to follow all of the
conventions and standards of the parent project, have the same
committers, have the same governing body, use the same mailing list,
etc., then it's not a separate project but rather a sub-project.
There are three aspects of incubation I would like to share: incubation
acceptance, technical requirements, and community health.
In incubation acceptance, the project seeking to incubate under Apereo
shows how it fits in with the organization. With regard to uPortal, it
is more defined -- how does the project fit in the uPortal ecosystem.
There should also be a predisposition to have in place or adopt an
acceptable license. Last, the project should demonstrate that it
provides usefulness to more than a single entity.
Technical requirements include licensing practices, public repos,
assigned committers, etc. In our sphere, these processes are usually
mirrors of the uPortal project. Often, only deviation from uPortal need
to be documented.
Community is one of the areas where Apereo incubating projects struggle.
Some have well established communities while many have none. With
uPortal, we already have a community. The effort for new uPortal related
projects is to find acceptance in the existing uPortal community rather
than establish it's own.
See https://www.apereo.org/content/apereo-incubation-process
uPortal ecosystem incubating projects can be streamlined, and some
should be considered sub-projects.
My 2 pence,
-bjagg
On 06/30/2017 06:49 AM, Aaron Grant wrote:
> Andrew,
>
> I'd say 1-2 years ago the incubation group voted saying portlets would
> no longer need to be incubated and under uPortal Steering Committee's
> control. Prior to that many portlets were being incubated. This change I
> believe was made due to the lack of mentors at the time maybe 25% of all
> incubated projects were portlets.
>
> Aaron
>
> On Fri, Jun 30, 2017 at 9:23 AM, Andrew Petro <andrew...@wisc.edu
> <mailto:andrew...@wisc.edu>> wrote:
>
> Reconsidering "We've long had a concept of grades of core-ness of
> Portlets associated with uPortal, *with none of those going through
> separate formal Incubation processes*."
>
> So uPortal-home is Incubating
> <http://uw-madison-doit.github.io/angularjs-portal/apereo-incubation.html>.
> <mailto:uportal-dev...@apereo.org>.
> <https://groups.google.com/a/apereo.org/group/uportal-dev/>.
> <mailto:uportal-dev...@apereo.org>.
Benito J. Gonzalez
Senior Software Developer
Unicon, Inc.
Voice: 480.558.2360
Text: 209.777.2754
Email: bgon...@unicon.net
GitHub: bjagg
GitLab: bjagg
BitBucket: bjagg
I agree with Aaron. There was some desire to move incubating portlets
and other small projects related to uPortal under uPortal Steering
Committee.
Notifications Portlet and Courses Portlet both went through JASIG
Incubation before the merger with Sakai. There were several portlets
other portlets as well.
My view is that microservices do not rise to the level of a project that
should be incubated. For these, we do not need additional adoption or
community. They should adhere to the practices of the parent project
(uPortal or uPortal-Home). Why were portlets even incubated?
I will be more precise. If the project is going to follow all of the
conventions and standards of the parent project, have the same
committers, have the same governing body, use the same mailing list,
etc., then it's not a separate project but rather a sub-project.
There are three aspects of incubation I would like to share: incubation
acceptance, technical requirements, and community health.
In incubation acceptance, the project seeking to incubate under Apereo
shows how it fits in with the organization. With regard to uPortal, it
is more defined -- how does the project fit in the uPortal ecosystem.
There should also be a predisposition to have in place or adopt an
acceptable license. Last, the project should demonstrate that it
provides usefulness to more than a single entity.
Technical requirements include licensing practices, public repos,
assigned committers, etc. In our sphere, these processes are usually
mirrors of the uPortal project. Often, only deviation from uPortal need
to be documented.
Community is one of the areas where Apereo incubating projects struggle.
Some have well established communities while many have none. With
uPortal, we already have a community. The effort for new uPortal related
projects is to find acceptance in the existing uPortal community rather
than establish it's own.
See https://www.apereo.org/content/apereo-incubation-process
uPortal ecosystem incubating projects can be streamlined, and some
should be considered sub-projects.
My 2 pence,
-bjagg
On 06/30/2017 06:49 AM, Aaron Grant wrote:
> Andrew,
>
> I'd say 1-2 years ago the incubation group voted saying portlets would
> no longer need to be incubated and under uPortal Steering Committee's
> control. Prior to that many portlets were being incubated. This change I
> believe was made due to the lack of mentors at the time maybe 25% of all
> incubated projects were portlets.
>
> Aaron
>
> On Fri, Jun 30, 2017 at 9:23 AM, Andrew Petro <andrew...@wisc.edu
> <mailto:andrew...@wisc.edu>> wrote:
>
> Reconsidering "We've long had a concept of grades of core-ness of
> separate formal Incubation processes*."
>
> I bet the history is more complicated than this. MyUW's hrs-portlets
> were in some kind of incubation at one point, for instance, with
> incubation failing for lack of engineering the portlets to be
> generally realizable. Jasig had an incubation process that predated
> Apereo's current incubation processes.
>
> So it's probably more accurate to say some uPortal ecosystem
> components historically participated in incubation processes, but
> not in very recent history and not in the incubation process as
> reconstituted in Apereo.
>
> On Thursday, June 29, 2017 at 2:53:23 PM UTC-5, Andrew Petro wrote:
>
> There are, concretely, today, a handful of microservice projects
> <https://apereo.github.io/2017/01/19/myuw-2016/#microservices>
> I bet the history is more complicated than this. MyUW's hrs-portlets
> were in some kind of incubation at one point, for instance, with
> incubation failing for lack of engineering the portlets to be
> generally realizable. Jasig had an incubation process that predated
> Apereo's current incubation processes.
>
> So it's probably more accurate to say some uPortal ecosystem
> components historically participated in incubation processes, but
> not in very recent history and not in the incubation process as
> reconstituted in Apereo.
>
> On Thursday, June 29, 2017 at 2:53:23 PM UTC-5, Andrew Petro wrote:
>
> There are, concretely, today, a handful of microservice projects
> loosely associated with uPortal-home. uPortal-home is formally
> incubating. So these microservices-for-use-with (dependencies?
> sub-projects?), they're, well, doing what exactly, in terms of
> incubation? Also incubating as implied sub-modules of
> uPortal-home? Need to enter incubation separately? Need the
> uPortal project to spin up its own lightweight incubator and
> then incubate in that? Something else?
>
> Background:
>
> (This is the email list follow up on a couple of Pull Requests
> <https://github.com/UW-Madison-DoIT/KeyValueStore/pull/18>.)
> incubating. So these microservices-for-use-with (dependencies?
> sub-projects?), they're, well, doing what exactly, in terms of
> incubation? Also incubating as implied sub-modules of
> uPortal-home? Need to enter incubation separately? Need the
> uPortal project to spin up its own lightweight incubator and
> then incubate in that? Something else?
>
> Background:
>
> (This is the email list follow up on a couple of Pull Requests
>
> So uPortal-home is Incubating
> <http://uw-madison-doit.github.io/angularjs-portal/apereo-incubation.html>.
> This incubation is a little unlike previous Apereo incubations
> in that uPortal-home isn't trying to become a standalone
> project, heavens no, it's trying to become a project within the
> uPortal ecosystem. Roughly, a component you'd be delighted to
> include in your campus portal implementation, but that you don't
> have to include. Ecosystem.
>
> More smaller relatively independent modules have some
> architectural advantages. Microservices and all that.
>
> Modeling these more smaller relatively independent modules as
> separate GitHub repos also has some advantages, in making the
> tooling work better. Want to keep an eye on thing X and not
> thing Y? Then watch thing X and not thing Y.
>
> The uPortal ecosystem should have more organisms. Oakland's
> lovely ReactJS-implemented course dashboard. Portal integrations
> for Edinburgh's enterprise notifications system. uPortal-home. A
> user profile application. Tools for academic advisors and
> students and course catelog user experiences and ....
>
> And of course the uPortal ecosystem already has a slew of
> organisms. They're Portlets. And ResourceServer. And Maven
> plugins. And supporting utility libraries. And Soffit samples
> <https://github.com/uPortal-Project/soffit-samples>. And ... .
> in that uPortal-home isn't trying to become a standalone
> project, heavens no, it's trying to become a project within the
> uPortal ecosystem. Roughly, a component you'd be delighted to
> include in your campus portal implementation, but that you don't
> have to include. Ecosystem.
>
> More smaller relatively independent modules have some
> architectural advantages. Microservices and all that.
>
> Modeling these more smaller relatively independent modules as
> separate GitHub repos also has some advantages, in making the
> tooling work better. Want to keep an eye on thing X and not
> thing Y? Then watch thing X and not thing Y.
>
> The uPortal ecosystem should have more organisms. Oakland's
> lovely ReactJS-implemented course dashboard. Portal integrations
> for Edinburgh's enterprise notifications system. uPortal-home. A
> user profile application. Tools for academic advisors and
> students and course catelog user experiences and ....
>
> And of course the uPortal ecosystem already has a slew of
> organisms. They're Portlets. And ResourceServer. And Maven
> plugins. And supporting utility libraries. And Soffit samples
> We've long had a concept of grades of core-ness of Portlets
> associated with uPortal, with none of those going through
> separate formal Incubation processes. Which isn't to say that
> they couldn't benefit greatly from some of the attention to
> detail and projectness that incubation brings to bear. But it is
> to say that to date uPortal hasn't built out formal processes to
> incubate, to more formally model the status of, these little
> modules.
>
> There are gains to be made in a bit more formality, a bit more
> care in characterizing these projects. Better characterizing the
> posture of the microservices came in part on the occasion of
> adding Christian Murphy as a uPortal-home committer. Does that
> imply committer status on these other projects as well? If it
> doesn't, well, then just how do those projects work, anyway?
>
> Where I think this is going:
>
> * We call these microservices uPortal Application Framework
> associated with uPortal, with none of those going through
> separate formal Incubation processes. Which isn't to say that
> they couldn't benefit greatly from some of the attention to
> detail and projectness that incubation brings to bear. But it is
> to say that to date uPortal hasn't built out formal processes to
> incubate, to more formally model the status of, these little
> modules.
>
> There are gains to be made in a bit more formality, a bit more
> care in characterizing these projects. Better characterizing the
> posture of the microservices came in part on the occasion of
> adding Christian Murphy as a uPortal-home committer. Does that
> imply committer status on these other projects as well? If it
> doesn't, well, then just how do those projects work, anyway?
>
> Where I think this is going:
>
> sub-projects out of pragmatism, so that they ride along with
> uPortal Home in its Incubation. Square them all away. Move
> them all over to a uPortal Project GitHub organization when
> we get there. This doesn't mean any less diligence about
> these -- they've gotta have licensing / markings /
> governance / everything all squared away to move. It does
> mean less blocking on inventing new uPortal project
> processes that do not currently exist.
> * We note again that this is a problem space with lots of
> uPortal Home in its Incubation. Square them all away. Move
> them all over to a uPortal Project GitHub organization when
> we get there. This doesn't mean any less diligence about
> these -- they've gotta have licensing / markings /
> governance / everything all squared away to move. It does
> mean less blocking on inventing new uPortal project
> processes that do not currently exist.
> opportunities for improvement and spin up some volunteers
> and work to realize more of these opportunities. It should
> be clearer how portlets and Soffit producers and
> microservices come into the ecosystem, what the grades of
> degrees of being in the ecosystem are, who has committer
> status over what how. It should be clear how very welcoming
> and ready and eager we are to pull a ReactJS based course
> dashboard project (Hi Oakland colleagues!) into the ecosystem.
>
> -Andrew
>
> --
> You received this message because you are subscribed to the Google
> Groups "uPortal Developers" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to uportal-dev...@apereo.org
> and work to realize more of these opportunities. It should
> be clearer how portlets and Soffit producers and
> microservices come into the ecosystem, what the grades of
> degrees of being in the ecosystem are, who has committer
> status over what how. It should be clear how very welcoming
> and ready and eager we are to pull a ReactJS based course
> dashboard project (Hi Oakland colleagues!) into the ecosystem.
>
> -Andrew
>
> --
> You received this message because you are subscribed to the Google
> Groups "uPortal Developers" group.
> To unsubscribe from this group and stop receiving emails from it,
> <mailto:uportal-dev...@apereo.org>.
> <https://groups.google.com/a/apereo.org/group/uportal-dev/>.
>
>
>
>
> --
> Aaron Grant
> Senior Applications Architect
> Oakland University - UTS <http://oakland.edu/uts>
>
>
>
> --
> Aaron Grant
> Senior Applications Architect
>
> --
> You received this message because you are subscribed to the Google
> Groups "uPortal Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to uportal-dev...@apereo.org
> --
> You received this message because you are subscribed to the Google
> Groups "uPortal Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> <mailto:uportal-dev...@apereo.org>.
Benito J. Gonzalez
Senior Software Developer
Unicon, Inc.
Voice: 480.558.2360
Text: 209.777.2754
Email: bgon...@unicon.net
GitHub: bjagg
GitLab: bjagg
BitBucket: bjagg
Reply all
Reply to author
Forward
0 new messages