On Tue, Jun 04, 2019 at 02:50:21PM +0200, Evilham wrote:
> 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*.
With regards to discoverability,
it's why there is a single pad which should be checked periodically and
takes a lot less effort than reading IRC backlogs, *various* mailing
lists, forum boards, and scouring through different Gitlab projects.
::
Re: [devuan-dev] Request for organi…
