[RFC] Allow fd.o to join forces with X.Org

[Eric Engestrom]

The leadership of freedesktop.org (fd.o) has recently expressed
interest
in having an elected governing body. Given the tight connection
between
fd.o and X.Org and the fact that X.Org has such a governing body it
seemed obvious to consider extending X.Org's mandate to fd.o.
Quite a bit of background on fd.o leading up to this has been covered
by
Daniel Stone at XDC 2018 and was covered really well by Jake Edge of
LWN [1].

If you'd like to watch Daniel's presentation, the recording is available on YouTube:

The slides are linked in the description.

One question that is briefly addressed in the LWN article and was
thoroughly discussed by members of the X.Org boards, Daniel Stone, and
others in hallway discussions is the question of whether to extend the
X.Org membership to projects hosted on fd.o but outside the purpose of
the X.Org foundation as enacted in its bylaws.
Most people I talked to would prefer not to dilute X.Org's mission and
extend membership only to contributors of projects that follow X.Org's
purpose as enacted in its bylaws. Other projects can continue to be
hosted on fd.o but won't receive X.Org membership for the mere reason
of
being hosted on fd.o.

With my member hat on, I think this is the best choice.

[1] https://lwn.net/Articles/767258/
- Subject line that better describes the intention
- Briefly describe reasons behind this change
- Drop expanding membership eligibility
---
We're looking for feedback and comments on this patch. If it's not
widely controversial the final version of the patch will be put to a
vote at the 2019 X.Org elections.
The patch applies to the X.Org bylaws git repo, which can be found at
https://gitlab.freedesktop.org/xorgfoundation/bylaws
Happy commenting.
Harry
bylaws.tex | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/bylaws.tex b/bylaws.tex
index 4ab35a4f7745..44ff4745963b 100644
--- a/bylaws.tex
+++ b/bylaws.tex
@@ -14,7 +14,7 @@ BE IT ENACTED AND IT IS HEREBY ENACTED as a By-law
of the X.Org Foundation
\begin{enumerate}[(i)\hspace{.2cm}]
- \item Research, develop, support, organize, administrate,
standardize,
+ \item \label{1} Research, develop, support, organize, administrate,
standardize,
promote, and defend a free and open accelerated graphics stack. This
includes, but is not limited to, the following projects: DRM, Mesa,
Wayland and the X Window System,
\item Support and educate the general community of users of this
graphics stack.
+
+ \item Support free and open source projects through the
freedesktop.org
+ infrastructure. For projects outside the scope of item (\ref{1})
support
+ extends to project hosting only.
+
\end{enumerate}
\article{INTERPRETATION}
--
2.19.1
_______________________________________________
Archives: https://foundation.x.org/cgi-bin/mailman/private/members
Info: https://foundation.x.org/cgi-bin/mailman/listinfo/members

_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/

[Peter Hutterer]

The leadership of freedesktop.org (fd.o) has recently expressed interest
in having an elected governing body. Given the tight connection between
fd.o and X.Org and the fact that X.Org has such a governing body it
seemed obvious to consider extending X.Org's mandate to fd.o.
Quite a bit of background on fd.o leading up to this has been covered by
Daniel Stone at XDC 2018 and was covered really well by Jake Edge of LWN [1].
One question that is briefly addressed in the LWN article and was
thoroughly discussed by members of the X.Org boards, Daniel Stone, and
others in hallway discussions is the question of whether to extend the
X.Org membership to projects hosted on fd.o but outside the purpose of
the X.Org foundation as enacted in its bylaws.
Most people I talked to would prefer not to dilute X.Org's mission and
extend membership only to contributors of projects that follow X.Org's
purpose as enacted in its bylaws. Other projects can continue to be
hosted on fd.o but won't receive X.Org membership for the mere reason of
being hosted on fd.o.
[1] https://lwn.net/Articles/767258/
- Subject line that better describes the intention
- Briefly describe reasons behind this change
- Drop expanding membership eligibility
---
We're looking for feedback and comments on this patch. If it's not
widely controversial the final version of the patch will be put to a
vote at the 2019 X.Org elections.
The patch applies to the X.Org bylaws git repo, which can be found at
https://gitlab.freedesktop.org/xorgfoundation/bylaws
Happy commenting.
Harry
bylaws.tex | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/bylaws.tex b/bylaws.tex
index 4ab35a4f7745..44ff4745963b 100644
--- a/bylaws.tex
+++ b/bylaws.tex
@@ -14,7 +14,7 @@ BE IT ENACTED AND IT IS HEREBY ENACTED as a By-law of the X.Org Foundation
\begin{enumerate}[(i)\hspace{.2cm}]
- \item Research, develop, support, organize, administrate, standardize,
+ \item \label{1} Research, develop, support, organize, administrate, standardize,
promote, and defend a free and open accelerated graphics stack. This
includes, but is not limited to, the following projects: DRM, Mesa,
Wayland and the X Window System,
\item Support and educate the general community of users of this
graphics stack.
+
+ \item Support free and open source projects through the freedesktop.org
+ infrastructure. For projects outside the scope of item (\ref{1}) support
+ extends to project hosting only.
+

Yes to the idea but given that the remaining 11 pages cover all the legalese
for xorg I think we need to add at least a section of what "project hosting"
means. Even if it's just a "includes but is not limited to blah". And some
addition to 4.1 Powers is needed to spell out what the BoD can do in regards
to fdo.

Cheers,
Peter

\end{enumerate}
\article{INTERPRETATION}
--
2.19.1

_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.

[Daniel Stone]

Post by Peter Hutterer

+ \item Support free and open source projects through the freedesktop.org
+ infrastructure. For projects outside the scope of item (\ref{1}) support
+ extends to project hosting only.
+

Yes to the idea but given that the remaining 11 pages cover all the legalese
for xorg I think we need to add at least a section of what "project hosting"
means. Even if it's just a "includes but is not limited to blah". And some
addition to 4.1 Powers is needed to spell out what the BoD can do in regards
to fdo.

Yeah, I think it makes sense. Some things we do:
- provide hosted network services for collaborative development,
testing, and discussion, of open-source projects
- administer, improve, and extend this suite of services as necessary
- assist open-source projects in their use of these services
- purchase, lease, or subscribe to, computing and networking
infrastructure allowing these services to be run

Cheers,
Daniel
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel

[Daniel Vetter]

Post by Daniel Stone

Post by Peter Hutterer

+ \item Support free and open source projects through the freedesktop.org
+ infrastructure. For projects outside the scope of item (\ref{1}) support
+ extends to project hosting only.
+

Yes to the idea but given that the remaining 11 pages cover all the legalese
for xorg I think we need to add at least a section of what "project hosting"
means. Even if it's just a "includes but is not limited to blah". And some
addition to 4.1 Powers is needed to spell out what the BoD can do in regards
to fdo.

- provide hosted network services for collaborative development,
testing, and discussion, of open-source projects
- administer, improve, and extend this suite of services as necessary
- assist open-source projects in their use of these services
- purchase, lease, or subscribe to, computing and networking
infrastructure allowing these services to be run

I fully agree that we should document all this. I don't think the
bylaws are the right place though, much better to put that into
policies that the board approves and which can be adapted as needed.
Imo bylaws should cover the high-level mission and procedural details,
as our "constitution", with the really high acceptance criteria of
2/3rd of all members approving any changes. Some of the early
discussions tried to spell out a lot of the fd.o policies in bylaw
changes, but then we realized it's all there already. All the details
are much better served in policies enacted by the board, like we do
with everything else.

As an example, let's look at XDC. Definitely one of the biggest things
the foundation does, with handling finances, travel sponsoring grants,
papers committee, and acquiring lots of sponsors. None of this is
spelled out in the bylaws, it's all in policies that the board
deliberates and approves. I think this same approach will also work
well for fd.o.

And if members are unhappy with what the board does, they can fix in
the next election by throwing out the unwanted directors.

Thanks, Daniel

[Peter Hutterer]

Post by Daniel Vetter

Post by Daniel Stone

Post by Peter Hutterer

+ \item Support free and open source projects through the freedesktop.org
+ infrastructure. For projects outside the scope of item (\ref{1}) support
+ extends to project hosting only.
+

Yes to the idea but given that the remaining 11 pages cover all the legalese
for xorg I think we need to add at least a section of what "project hosting"
means. Even if it's just a "includes but is not limited to blah". And some
addition to 4.1 Powers is needed to spell out what the BoD can do in regards
to fdo.

- provide hosted network services for collaborative development,
testing, and discussion, of open-source projects
- administer, improve, and extend this suite of services as necessary
- assist open-source projects in their use of these services
- purchase, lease, or subscribe to, computing and networking
infrastructure allowing these services to be run

I fully agree that we should document all this. I don't think the
bylaws are the right place though, much better to put that into
policies that the board approves and which can be adapted as needed.
Imo bylaws should cover the high-level mission and procedural details,
as our "constitution", with the really high acceptance criteria of
2/3rd of all members approving any changes. Some of the early
discussions tried to spell out a lot of the fd.o policies in bylaw
changes, but then we realized it's all there already. All the details
are much better served in policies enacted by the board, like we do
with everything else.
As an example, let's look at XDC. Definitely one of the biggest things
the foundation does, with handling finances, travel sponsoring grants,
papers committee, and acquiring lots of sponsors. None of this is
spelled out in the bylaws, it's all in policies that the board
deliberates and approves. I think this same approach will also work
well for fd.o.
And if members are unhappy with what the board does, they can fix in
the next election by throwing out the unwanted directors.

yeah, fair call. though IMO in that case we can just reduce to

\item Support free and open source projects through the freedesktop.org
infrastructure.

because my gripe is less with the fdo bit but more with defining what
"project hosting" means, given that we use that term to exclude fdo projects
from getting anything else. I think just dropping that bit is sufficient.

Cheers,
Peter
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: htt

[Daniel Vetter]

Hi,

Post by Peter Hutterer

Post by Daniel Vetter

Post by Daniel Stone
- provide hosted network services for collaborative development,
testing, and discussion, of open-source projects
- administer, improve, and extend this suite of services as necessary
- assist open-source projects in their use of these services
- purchase, lease, or subscribe to, computing and networking
infrastructure allowing these services to be run

I fully agree that we should document all this. I don't think the
bylaws are the right place though, much better to put that into
policies that the board approves and which can be adapted as needed.
Imo bylaws should cover the high-level mission and procedural details,
as our "constitution", with the really high acceptance criteria of
2/3rd of all members approving any changes. Some of the early
discussions tried to spell out a lot of the fd.o policies in bylaw
changes, but then we realized it's all there already. All the details
are much better served in policies enacted by the board, like we do
with everything else.
As an example, let's look at XDC. Definitely one of the biggest things
the foundation does, with handling finances, travel sponsoring grants,
papers committee, and acquiring lots of sponsors. None of this is
spelled out in the bylaws, it's all in policies that the board
deliberates and approves. I think this same approach will also work
well for fd.o.
And if members are unhappy with what the board does, they can fix in
the next election by throwing out the unwanted directors.

yeah, fair call. though IMO in that case we can just reduce to
\item Support free and open source projects through the freedesktop.org
infrastructure.
because my gripe is less with the fdo bit but more with defining what
"project hosting" means, given that we use that term to exclude fdo projects
from getting anything else. I think just dropping that bit is sufficient.

Hm yeah, through the lens of "everything not explicitly listed isn't in
scope as X.org's purpose", leaving this out is probably clearest. And
under 2.4 (i) the board already has the duty to interpret what exactly
this means wrt membership eligibility.
Harry, Daniel, what do you think?

Yeah, that's fine. I didn't specifically want the enumerated list of
what we do in the bylaws, just spelling it out for background as a
handy reference I could point to later. I think maybe we could reduce
Administer, support, and improve the freedesktop.org hosting
infrastructure to support the projects it hosts

This feels a bit self-referential, not the best for the purpose of
what X.org does. If we do want to be a bit more specific we could do
something like with (i) and provide a list that the board can extend:

\item Support free and open source projects through the freedesktop.org
infrastructure. This includes, but is not limited to:
Administering and providing
project hosting services.

That would make it clear that admins&servers are in scope, and
everything else is up to the board. Similar to how drm, mesa, wayland
and X are explicitly in scope, and stuff like cros/android gfx stack
or libinput is up to the board to decide/clarify.

Gives us enough scope to grow in the future (e.g. we don't need a
bylaws change to move from pure-git to GitLab), avoids the sticky
question of what exactly fd.o hosts in the bylaws (e.g. if
NetworkManager needs a new repo then we don't have to consult
membership to add it), but is still pretty firmly limited in scope.
Any of the above have my in-principle ack though, I think they're all
reasonable colours for our lovely shed.

Well, one more bikeshed from me!

Cheers, Daniel

Cheers,
Daniel

[Daniel Vetter]

Post by Daniel Vetter

Hi,

Post by Peter Hutterer

Post by Daniel Vetter

Post by Daniel Stone
- provide hosted network services for collaborative development,
testing, and discussion, of open-source projects
- administer, improve, and extend this suite of services as necessary
- assist open-source projects in their use of these services
- purchase, lease, or subscribe to, computing and networking
infrastructure allowing these services to be run

I fully agree that we should document all this. I don't think the
bylaws are the right place though, much better to put that into
policies that the board approves and which can be adapted as needed.
Imo bylaws should cover the high-level mission and procedural details,
as our "constitution", with the really high acceptance criteria of
2/3rd of all members approving any changes. Some of the early
discussions tried to spell out a lot of the fd.o policies in bylaw
changes, but then we realized it's all there already. All the details
are much better served in policies enacted by the board, like we do
with everything else.
As an example, let's look at XDC. Definitely one of the biggest things
the foundation does, with handling finances, travel sponsoring grants,
papers committee, and acquiring lots of sponsors. None of this is
spelled out in the bylaws, it's all in policies that the board
deliberates and approves. I think this same approach will also work
well for fd.o.
And if members are unhappy with what the board does, they can fix in
the next election by throwing out the unwanted directors.

yeah, fair call. though IMO in that case we can just reduce to
\item Support free and open source projects through the freedesktop.org
infrastructure.
because my gripe is less with the fdo bit but more with defining what
"project hosting" means, given that we use that term to exclude fdo projects
from getting anything else. I think just dropping that bit is sufficient.

Hm yeah, through the lens of "everything not explicitly listed isn't in
scope as X.org's purpose", leaving this out is probably clearest. And
under 2.4 (i) the board already has the duty to interpret what exactly
this means wrt membership eligibility.
Harry, Daniel, what do you think?

Yeah, that's fine. I didn't specifically want the enumerated list of
what we do in the bylaws, just spelling it out for background as a
handy reference I could point to later. I think maybe we could reduce
Administer, support, and improve the freedesktop.org hosting
infrastructure to support the projects it hosts

This feels a bit self-referential, not the best for the purpose of
what X.org does. If we do want to be a bit more specific we could do
\item Support free and open source projects through the freedesktop.org
Administering and providing
project hosting services.

I like this phrasing, but won't that bring us back to David Hutterer's
point about defining what "project hosting services" means?
Personally I think "project hosting" is quite clear and shouldn't need to be defined.

I think it's less tricky, since we no longer use it to exclude services
and support. It makes it much more clear that defining the details is all
up to the board, with just a rough guideline of what should be included.

Peter?
-Daniel

Harry

Post by Daniel Vetter
That would make it clear that admins&servers are in scope, and
everything else is up to the board. Similar to how drm, mesa, wayland
and X are explicitly in scope, and stuff like cros/android gfx stack
or libinput is up to the board to decide/clarify.

Gives us enough scope to grow in the future (e.g. we don't need a
bylaws change to move from pure-git to GitLab), avoids the sticky
question of what exactly fd.o hosts in the bylaws (e.g. if
NetworkManager needs a new repo then we don't have to consult
membership to add it), but is still pretty firmly limited in scope.
Any of the above have my in-principle ack though, I think they're all
reasonable colours for our lovely shed.

Well, one more bikeshed from me!
Cheers, Daniel

Cheers,
Daniel