[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 at fooishbar.org> wrote:
>>
>> Hi,
>>
>> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter <daniel at 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 at 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
> 
> 
>