Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Architecture Council Subcommittees

The discussion below about things being hard-wired into the bylaws, etc., raises and interesting question: Why not propose changes to the AC to the board and have those by laws changed to better reflect what this body needs to do?

For example, why not propose the changes below for the AC and maybe something even more drastic like moving mentoring to a separate Mentors Council? (Just spitballing...) The point is that the Board has been rather progressive lately, in my opinion, so we might as well strike while the iron is hot. It never hurts to ask!

Jay

Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings
________________________________________
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx <eclipse.org-architecture-council-bounces@xxxxxxxxxxx> on behalf of Julien Vermillard <jvermillard@xxxxxxxxxxxxxxxxxx>
Sent: Friday, November 11, 2016 9:31 AM
To: eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] Architecture Council Subcommittees

On Thu, Nov 10, 2016 at 09:32:02AM -0800, Wayne Beaton wrote:
> Greetings folks
>
> (there's an interesting part about Language Server Protocol near the bottom; be
> sure to read this all the way through)
>
> As discussed on the call today, I would like to propose that we refocus the
> Architecture Council on the larger picture to become more inclusive of the
> broad scope of projects that call the Eclipse Foundation home. While many of us
> are, for example, very interested in discussing topics related to the Eclipse
> IDE, a great many of us have nothing to offer on the topic.
>
> According to the bylaws,
>
>     The Eclipse Management Organization shall establish an Architecture Council
>     responsible for: (i) monitoring, guiding, and influencing the software
>     architectures used by Projects, (ii) new project mentoring, and (iii)
>     maintaining and revising the Eclipse Development Process subject to the
>     approval of the Board under Section 3.9(c).. ... The Architecture Council
>     will accomplish its objectives by working closely with the development
>     teams.
>
> I propose that we refocus our monthly "all hands" calls to focus specifically
> on the responsibilities outlined in the Bylaws. We should, for example,
> highlight issues of concern for projects with regard to process and discuss
> alternatives. I'd really like, for example, to find some resolution on how we
> revise the EDP to let fast moving new projects release very frequently.a

Obviously +1 on refocussing

yes releasing is painful, the only way to release often is to release
milestone and/or avoid to upgrade your dependencies.
Type A will probably help projects who want to release often.

>
> The interesting sorts of focused discussions can then be moved to
> subcommittees. This is happening already with the IDE-DEV mailing list and with
> the new FEEP stakeholders mailing list that MIkael announced earlier today.
>
> I've added a section titled "Subcommittees" on the AC landing page [1]. I don't
> think that we need a lot of formality in the concept of a subcommittee. There
> is no need, for example, to modify the bylaws or the EDP and I don't think that
> we need to do anything more formal than to just capture the existence and
> communication channels for each subcommittee (and, I guess, make sure that we
> clean them up when they become inactive). It's pretty easy already to just ask
> the Webmaster to create a new mailing list. We can just use the AC conference
> line (or easily create a new one) if any subcommittee wants to set up calls.
>
> On each of our "all hands" calls, we can require that each subcommittee deliver
> a (short) overview of their status, let members of the AC know why they might
> want to get involved in the discussion, and otherwise seek help where help from
> the broader community is required.
>
> As we also discussed on the call today, I think that we should stand up a new
> subcommittee to guide our efforts around the Language Server Protocol. We have
> several existing projects that are focused on this and have added several new
> projects. We have an excellent opportunity to provide guidance and coordination
> for these projects. The following projects come immediately to mind: Xtext,
> Che, JDT LS, LSP4J, and LSP4e (did I miss anybody?)
>
> Who is interested in providing some leadership in this subcommittee? The first
> step is decide among yourselves who will take the lead, then connect with the
> webmaster to provision the required resources, and update the ''Subcommittees''
> section on the AC Landing page. Let me know how I can help.
>
> Thoughts, concerns?
>
> Wayne
>
> [1] https://wiki.eclipse.org/Architecture_Council#Subcommittees
>
> --
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation

> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


--
Julien Vermillard
Mobile: +33680328665
jvermillard@xxxxxxxxxxxxxxxxxx :: https://www.sierrawireless.com
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.



Back to the top