RE: GitHub organization discussed at FOSDEM

[Thijs Schreijer <thijs@...>]

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Hisham
> Sent: zaterdag 21 februari 2015 4:54
> To: Lua mailing list; diego@tecgraf.puc-rio.br; Tomas Guisasola Gorham;
> Matthew Wild
> Subject: Re: GitHub organization discussed at FOSDEM
> 
> On 20 February 2015 at 16:38, Thijs Schreijer <thijs@thijsschreijer.nl>
> wrote:
> >
> >> -----Original Message-----
> >> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> >> Behalf Of Pierre Chapuis
> >> Sent: vrijdag 20 februari 2015 16:03
> >> To: lua-l@lists.lua.org
> >> Subject: GitHub organization discussed at FOSDEM
> >>
> >> Hello list,
> >>
> >> at FOSDEM we discussed the possibility of creating a GitHub organization
> >> to maintain some Lua modules for which there should be several
> maintainers
> >> (for instance LuaSocket, and probably some libraries from the Kepler
> >> project).
> >>
> >> I wanted to float that idea here again, and maybe start moving on it.
> 
> Thanks for bringing it up!!
> 
> >> So I have a few questions:
> >>
> >> 1) How do you want to call this organization?
> >> 2) Who wants to be part of it?
> >> 3) Who wants to create it?
> >
> > Can't the existing Kepler organization [1] be used?
> > Wouldn't that be easiest?
> 
> Yeah, I remember that suggestion from the fruitless
> new-LuaForge/new-Lua-for-Windows discussions (which were long and
> didn't produce results, so I'm willing to go to something way more
> focused this time).
> 
> I brought up "Kepler" as a possibility at FOSDEM, but IIRC more than
> one person mentioned that this name carried too much historical
> baggage, and/or would be confusing, and/or brings the issue of
> unmaintained Kepler modules getting in the mix.
> 
> > If one of the current owners [2] (Fabio, Andre or Hisham)
> > could create a new team for LuaSocket and Diego would
> > hand it over...
> >
> > Now who should be on that team? Diego obviously, but
> > probably also someone else... looking at the contributors [3]
> > there are some Lua commoners there. What is mostly needed
> > I think is someone that can intelligently discuss PR's and
> > merge them. Let the community do the development, if
> > nobody codes a fix for an issue, the need isn't big enough.
> 
> What you described is quite in line with what we discussed at FOSDEM.
> (I hope someone took pictures of the blackboard at the end of the
> meeting :) )
> 
> When I mean going with something focused, I mean to avoid the old
> Grand Plans we tried in the past that produce lots and lots of
> discussions/opinions/bikeshedding and little results. So no trying to
> fix the perennial issues of "batteries", "all-in-one packages",
> "one-stop-shop for high quality modules", "set of modules made to work
> for each other" or "blessed modules". (All of these are nice wishes,
> but beyond the scope.)

Some pragmatism would really help this time :)

> 
> What we came up with there then was, if my memory serves me right, the
> following assessment of the situation:
> 
> * There are modules which have people who are interested in them, but
> which don't have a clear maintenance status (are they maintained? by
> who? is the 3-year old code in github lying there because it's
> abandoned or is it because it "just works"? etc.)
> 
> * Diego says he wants to hand over maintenance of LuaSocket. A few
> people offered to be part of a maintenance team, but no one stepped
> forward "I'll be the one maintainer". Understandably, no one wants to
> risk themselves to be in Diego's position (out of free time and with
> the responsibility of Lua's most important module). The obvious
> solution is to switch to a "maintenance team" model.
> 
> * The status of some Kepler projects is unclear. Since I have write
> access to them all, I've been merging trivial/obviously-right pull
> request that people send to them lately, but I'm not really a
> maintainer to these projects. We need to figure out what to do with
> them (if anything).
> 
> * Sometimes there are different people working on the same project but
> in a uncoordinated/alternating manner. LuaExpat is an example of that.
> I had the opportunity to meet Matthew at FOSDEM (and then have lunch
> with Tomás after I returned to Rio) so it was nice to get both
> perspectives. It's clear to me that collaboration can easily happen,
> it's just a matter of having the mechanisms. (Also, we need to drag
> Tomás to one of the Lua Workshops — he's one of the unsung heroes of
> the Lua module world :) ).
> 
> So, the concrete proposal boiled down to this:
> 
> * We create an organization in GitHub (essentially a group account,
> like http://github.com/keplerproject ) which will host some projects
> 
> * The criteria for hosting them in this org will be simple: it will
> host modules being maintained by two or more maintainers. This way,
> people can join, leave and the project keeps its continuity, without
> people having to figure out which fork in GitHub is the maintained
> one.
> 
> * If maintainers leave the project to the point that there's a single
> remaining maintainer, the remaining one can ask for volunteers to join
> in lua-l, and if no one comes up, the project is moved out of the org
> and into the sole maintainer's account.
> 
> * This way, instead of a subjective selection of modules (some
> maintained and some abandoned) like in Kepler, looking at the projects
> in the org you'll have at least the guarantee that (a) they are not
> abandoned, (b) there are at least two people who use/like/maintain
> this project. (So it is to an extent a metric of curation, but a
> concrete one.)
> 
> If I'm misrepresenting anything that was discussed in the BoF, please
> do correct me! It's been weeks!
> 
> There are probably other practical details to decide (For example, how
> long does it take until a project is abandoned? My suggestion is to do
> a yearly review to check if maintainers are still involved/reachable.)
> 
> And then we get to Pierre's questions:
> 
> 1) How do you want to call this organization?
> 
> As I told Justin over lunch after the BoF meeting, this is probably
> the hardest question. :) luateam is obviously taken by the Lua Team,
> luausers was suggested in the BoF might be confusing with the
> lua-users.org wiki... luacommunity? I like the sound of it.
> 
> 2) Who wants to be part of it?
> 
> I think it's a matter of seeing which projects we start moving, and
> who volunteers to their maintenance teams. LuaSocket and LuaExpat
> would be two obvious initial candidates.
> 
> I'm pretty swamped by the bunch of stuff that I already maintain so I
> won't joining maintenance of any new projects, but since I have admin
> access to the keplerproject org and we'll probably do some migrating,
> I volunteer to perform general account administrivia (again, in the
> spirit of the idea, we need at least one more admin, IMO preferrably
> someone outside of LabLua — Pierre?).
> 
> 3) Who wants to create it?
> 
> I can kickstart it and I can also move LuaRocks to this new org, as
> its development is already done collectively (and in particular I'm
> grateful to Thijs and Ignacio for allowing me to not have to take care
> of the Windows parts!). Also, http://github.com/luacommunity/luarocks
> is a cute URL. :)
> 
> -- Hisham

Thx for your clear writeup and offer to kickstart. I like the approach outlined.

But I'd prefer to clean up instead of adding to the mess. There are two existing projects; Kepler and LuaForge, so please don't add new stuff to the equation

My 2cts;
- use LuaForge for anything abandoned and up-for-grabs for anyone who wishes to take over maintenance
- use Kepler for the method described above (team based)
This might involve moving some Kepler stuff over to LuaForge

@Hisham; No need to take my approach, but most of all; be pragmatic, and make the change. This list has a bad reputation for consensus, so waiting won't help :)

Thijs