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

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

[Harry Wentland]

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/

v2:
 - 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
 
 The purpose of the X.Org Foundation shall be to:
 \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,
@@ -24,6 +24,11 @@ The purpose of the X.Org Foundation shall be to:
 
 	\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

_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Eric Engestrom]

On October 15, 2018 2:50:13 PM UTC, Harry Wentland <harry.wentland@amd.com> wrote:
> 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:
https://youtu.be/s22B3E7rUTs

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.
Acked-by: Eric Engestrom <eric@engestrom.ch>

> 
> [1] https://lwn.net/Articles/767258/
> 
> v2:
>  - 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
>  
>  The purpose of the X.Org Foundation shall be to:
>  \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,
> @@ -24,6 +24,11 @@ The purpose of the X.Org Foundation shall be to:
>  
>  	\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
> 
> _______________________________________________
> members@foundation.x.org: X.Org Foundation Members
> Archives: https://foundation.x.org/cgi-bin/mailman/private/members
> Info: https://foundation.x.org/cgi-bin/mailman/listinfo/members
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Peter Hutterer]

On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> 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/
> 
> v2:
>  - 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
>  
>  The purpose of the X.Org Foundation shall be to:
>  \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,
> @@ -24,6 +24,11 @@ The purpose of the X.Org Foundation shall be to:
>  
>  	\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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Daniel Stone]

On Tue, 16 Oct 2018 at 08:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > +     \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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Daniel Vetter]

On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone <daniel@fooishbar.org> wrote:
>
> On Tue, 16 Oct 2018 at 08:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > +     \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

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

[Peter Hutterer]

On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone <daniel@fooishbar.org> wrote:
> >
> > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > > +     \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
> 
> 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-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

[Daniel Vetter]

On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone <daniel@fooishbar.org> wrote:
> > >
> > > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > > > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > > > +     \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
> > 
> > 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?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Daniel Stone]

Hi,

On Fri, 26 Oct 2018 at 11:57, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone <daniel@fooishbar.org> wrote:
> > > > 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
> > >
> > > 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
it to something like:
  Administer, support, and improve the freedesktop.org hosting
infrastructure to support the projects it hosts

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.

Cheers,
Daniel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Daniel Vetter]

On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone <daniel@fooishbar.org> wrote:
>
> Hi,
>
> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone <daniel@fooishbar.org> wrote:
> > > > > 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
> > > >
> > > > 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
> it to something like:
>   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
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Wentland, Harry]

On 2018-10-26 7:22 a.m., Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone <daniel@fooishbar.org> wrote:
>>
>> Hi,
>>
>> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
>>>> On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
>>>>> On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone <daniel@fooishbar.org> wrote:
>>>>>> 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
>>>>>
>>>>> 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
>> it to something like:
>>   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.
> 

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.

Harry

> 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
> 
> 
> 
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Daniel Vetter]

On Mon, Oct 29, 2018 at 01:24:56PM +0000, Wentland, Harry wrote:
> On 2018-10-26 7:22 a.m., Daniel Vetter wrote:
> > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone <daniel@fooishbar.org> wrote:
> >>
> >> Hi,
> >>
> >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> >>>> On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> >>>>> On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone <daniel@fooishbar.org> wrote:
> >>>>>> 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
> >>>>>
> >>>>> 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
> >> it to something like:
> >>   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.
> > 
> 
> 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
> 
> > 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
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev