Re: GitHub organization discussed at FOSDEM

[Hisham <h@...>]

On 23 February 2015 at 20:06, Chris Berardi <cberardi32@gmail.com> wrote:
>> 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.)
>
> A couple other things that come to mind are:

Great points raised, thank you!

>   * Should be be a distinction between the current maintainers/leaders and
>     those that are other contributors?
>   * Should this distinction be democratic (e.g., current maintainers/leaders
>     voted from and by the current contributors)?
>   * What mechanism will be in place to allow an interested person to become
>     involved in a particular project?

I think all of that is up to the project. This would be just a common
place for projects, without any particular restrictions/guidelines on
how the project is managed.

I don't know if was evident to those looking from the outside, but
Kepler (back in the original funded project) had some strict
guidelines applied to projects released under its banner: (a) they
were all portable, running at least on Linux, Windows and Mac; (b)
they were all documented, and each release had matching documentation
updates; (c) they all ran on the latest Lua version, many retaining
compatibility with Lua 5.0 and 5.1; (d) they were all designed to work
well with each other. These are all great features to have, but this
is all outside of the scope of what at least I am bringing up on this
thread.

>   * Should the yearly review include reviewing how the project is attracting
>     and incorporating new contributors to it? I think this is important to
>     maintain and sustain a project.

In the same vein, I'd say no. In the end this is a form of subjective
curation and therefore outside of the scope (at least I'm not
intending to do it; lua-toolbox.com, hopefully integrated with
luarocks.org in the future, is a better approach IMO). Yes, attracting
and incorporating new contributors is useful to maintain and sustain a
project (though not essential: Lua itself has held its own pretty well
for 20+ years relying on the same three people), but this is not
Kepler in a sense that Kepler was an umbrella organization
"recommending" a set of projects (least of all in combination).

I liked the idea of reusing the Kepler name when we were discussing
making it the "batteries" project for the next LuaForWindows, but for
this thing we're talking here, I'm pretty much convinced it doesn't
make sense. And that's also why I was recommending an understated name
such as luacommunity — all of us are already members of the "Lua
community" (meaning all "community projects" (i.e. not individual
projects) are welcome) and the name does not imply anything else about
the projects other than that (while all the other cool names suggested
would raise questions on "What XYZ actually is"). Perhaps an even
blander name such as luacommunityprojects or luauserprojects, just to
make clear that the repos are not centrally coordinated as part of an
over-arching project.

An alternative, of course, is to simply ditch the whole idea and move
any projects people are interested in maintaining collectively into
their own GitHub orgs, such as http://github.com/luasocket/luasocket,
and be done with it. What exactly do we gain from having a common org?
The only ones I really see now is: (a) promoting a culture of
collective maintainership; (b) more visibility to new projects due to
being next to well-known ones in the same repo (with (a) of course
being the important one).

-- Hisham