Am 13/09/2017 um 16:41 schrieb John Franklin:
>> On Sep 13, 2017, at 2:11 AM, KatolaZ <katolaz@???> wrote:
>>
>> On Wed, Sep 13, 2017 at 12:24:49AM +0200, Ivan J. wrote:
>>
>> [cut]
>>
>>>> So, how can we get through this and keep it from happening again?
>>>> If the project is to move forward, the root issues leading to the
>>>> current state of affairs have to be resolved.
>>>>
>>>> Thoughts?
>>> There's not much to it besides letting people with actual time do
>>> things...
>>>
>> Totally agree with parazyd. And the latest discussions we have had are
>> all about that: help people to help Devuan.
>>
>> On the recent apparent reduction in Devuan's activity, let's please
>> try to leave the drama aside. Nobody said much when people were
>> working almost exclusively on Devuan for several weeks to push Jessie
>> out (that was not normal either). Having alternating activity bursts
>> is in the very nature of voluntary projects, like it or not.
> This was my impression, too. Less a “crisis of governance” and more a slump in momentum, possibly compounded by the European summer vacation.
>
> I’d like to support Devuan any way I can, but my time for another project is limited. It is easiest when I can do it as part of another project.

[cut]

> Where I can, I’ll use Devuan as the underlying OS, and I’ll promote it as a viable alternative, but I need confidence that security updates will make it to the repositories in a timely manner. That will require Devuan to have a robust CI pipeline, and I know that build-out is in progress. I mention it here to provide a little p̵r̵e̵s̵s̵u̵r̵e̵ encouragement to keep up the good work.

We all have the same issue, that's why it's a volunteer project; in
theory enough people step in, so that we cover each other's work and
life peaks that translate in less project activity.

IMO, disregarding what *is* an issue as something transitory or
in-existent is a mistake. Also notice I avoided pointing fingers, the
email was not meant to create drama, it was meant as a warning shot.
Overall, something is not quite working right and we should consider
ways of approaching that.

One thing that comes to mind is, as part of the infra docs, also
document who has access to what; I guess this should be public anyway.
Then making sure that at *any point*, *at least two people* have access
to *any resource*.

This is in line with things proposed by others before, just in a more
generic fashion and adding some availability / communication compromise.

That is, if person A responsible for resource R is going to be away for
a while, letting everyone know is *the* thing to do; then if person B,
also responsible for resource R, is has to excuse themselves, they
can/should plan for what would happen with resource R in absence of both
A and B.

Maybe it's acceptable for R to be unavailable in a short period of time,
maybe it makes sense to give access to R to a person C, maybe A or B can
make themselves available for short timeslots in case something relating
resource R is needed.

In any case, more communication, accountability and transparency is
needed. If asking "who has access to R" takes weeks to have an answer,
then whatever has to be done with that resource is going to take months.

Basically, knowing who to bug (and how, and when) about any specific
part at any point would be of benefit.
--
Evilham