Re: Defining GNOME software (finally)

[Allan Day <aday gnome org>]

Thanks for the reply Michael - very helpful!

Michael Catanzaro <mcatanzaro gnome org> wrote:
...
> So I propose that
> we have the wiki page say that the canonical definition of "what is
> GNOME?" is the list of BuildStream elements listed in
> meta-gnome-core-developer-tools.bst, meta-gnome-core-os-services.bst,
> meta-gnome-core-shell.bst, and meta-gnome-core-utilities.bst.

I was wondering the same thing - this sounds good to me!

> Note it
> intentionally does not include SDK components like GTK or GLib. We
> could potentially expand the definition to include SDK components
> hosted on gitlab.gnome.org, but that would require splitting up sdk.bst.

If those components are relatively stable, could we just list them on
the wiki somewhere? Whatever path offers least resistance is probably
the way to go.

> To make sure we don't have misplaced expectations, please remember that
> this list cannot be used for deciding what repositories go into the
> GNOME/ group on GitLab, because probably 90% of the stuff currently
> there is not core and is therefore excluded from our definition, and
> also because we add and remove things from core on a semi-regular basis
> (e.g. we just removed gnome-themes-extra earlier this week). I continue
> to recommend allowing experienced GNOME developers to create new
> repositories there as needed.

I don't want to comment on the legal aspect of this too much, but we
probably do need a Foundation policy to cover what goes into that
group. At the same time, your point is a good one - we don't want
avoid frequent changes in the Gitlab group membership. The answer to
that is probably to have some exceptions in place in the policy, to
give us a bit of flexibility. We'll figure out the details of that.

> > We'll also need you to confirm that the member list [2] is
> > up to date.
>
> That member list is kept up to date, yes.

Great, thanks!

> > We'd also like to know if you want to keep the Release Team name, or
> > whether you'd prefer to switch to "Release Committee" or "Engineering
> > & Release Committee", or anything else. It's up to you.
>
> I think we're fine with release team.

I thought you'd say that. :)

> > You should also know that becoming a committee will involve some small
> > changes [3]:
> >
> >   - You'll need to have membership changes ratified by the board
> >   - You'll need to have a chair, and minuted meetings

Any suggestions for who should be chair?

> >   - You'll need to keep the board informed about how things are going
>
> Having membership changes ratified seems fairly low cost. We normally
> hold one formal meeting per year, which we take private notes on, so
> the only change there would be to make those minutes formal and public.

There's no requirement for minutes to be public. However, if the
Release Team is a committee it probably make sense for minutes to be
accessible to the Foundation (ie. Board, ED, etc).

> Most of our decision-making occurs on IRC, and not as part of any
> formally organized meeting, and therefore is not minuted.

I don't have much concrete advice regarding when meetings should be
held. My suggestion would be to have them whenever a non-routine
decision has to be made.

Thanks again,

Allan