On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote:
>
> Hi,
>
> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
