On 2018-10-26 7:22 a.m., Daniel Vetter wrote: > 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. > 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 > > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
