On dt., juny 04 2019, katolaz@??? wrote:

> On Tue, Jun 04, 2019 at 08:18:54PM +0900, Olaf Meeuwissen wrote:
>>
>> Devuan has a GitLab instance. Why not use its issues? With a
>> suitable
>> set of priority labels and people assigning issues to
>> themselves, the
>> workflow would be pretty much the same as below.
>>
>
> I probably shouldn't intervene on this, but I guess past
> experience is
> useful in making decisions: the usage of gitlab issues to signal
> bugs
> and things to do was what effectively stalled and delayed Devuan
> Jessie release by more than one year and a half. The few
> developers
> had to cope with issues scattared all around the place, with no
> idea
> of what needed to be done in order to have the release ready.
> The
> turning point there was to have all the issues manually
> collected from
> all the different gitlab projects and collated (and tagged) into
> bugs.devuan.org. At that point we knew what needed to be done
> and
> worked for it. Jessie was released three months after that
> collation
> work was completed.
>
> IMHO gitlab issues work well only if you have many developers,
> each of
> them supervising just a couple of projects, and only those. In
> that
> case it is clear who should take care of which issue. If you
> have only
> a handful of people who need to do whatever needs to be done,
> all over
> the place, then a pad would be much more efficient, IMHO.
>
> Sorry
>
> KatolaZ


I mostly agree with this, which is why my original reply to
parazyd was going to be "LGTM" (quotes included).

The quotes were because: yes, it solves some issues.
But Devuan is at a stage where organisation beyond that is needed,
as evidenced by Ralph's suggestions re: timestamps and so on.

Quoting the relevant bits of one of my previous attempts that died
in a sea of silences:

 #### Workflow, accountability and transparency
    [ ] Foster more availability/(close-to) real-time
    communication
    [ ] Create next week's pad immediately after finishing a
    weekly meeting
        --> This means we can use the pad over the week as a
        "brain-dump" space
        - (gl) This has not worked to date
    [ ] It has to be possible to know what is being worked on, by
    whom and which deadlines are not met
        (Evilham): I am very tempted to propose setting up
        redmine for the project...
                   It can help with many of these things. Better
                   alternatives are welcome.
    [ ] Discoverability of knowledge is an issue.
        Even a pad prominently linked from the main IRC channel
        can be missed:
        https://pad.dyne.org/code/#/1/edit/YakleTpFfQ9KHXt+ggqgSQ/BJYL0QHRoy9LmLEObTTKmzAH/

None of that is addressed in a "let's centralise tasks in a pad"
approach.
But since it is better than the 'nothing' that there is right now
and no interest was shown in even debating something else, I go
back to my original "LGTM".

Just stressing that accountability and communication of work on
infra should be priorities.

All of this is of course just my opinion, take into account or
don't; in the end *something* gets done *somehow*.
--
Evilham