On Tue, Jun 04, 2019 at 07:56:51PM -0500, golinux@??? wrote:
> On 2019-06-04 18:30, Ivan J. wrote:
> > On Tue, Jun 04, 2019 at 03:30:12PM -0500, golinux@??? wrote:
> > > On 2019-06-04 04:07, Ivan J. wrote:
> > > > Hello devs.
> > > >
> > > > I would like to propose an asynchronous task workflow that might benefit
> > > > all of us. I'm saying asynchronous, because due to our timezone
> > > > differences, and after all, general availability, we are not all able to
> > > > be in the same place at the same time to discuss things.
> > > >
> > > > My idea is to have a central pad that we can always access and place
> > > > tasks that need attendance in order of urgency on it. Something in
> > > > this[0] manner.
> > > >
> > >
> > > We have tried this approach many times like the "Post-ASCII Devuan
> > > bikeshed"
> > > mentioned by Evilham. My cryptpad drive is littered with such
> > > carcasses erm
> > > . . . pads. Pads kind of work but only if they are actively and
> > > continuously
> > > visited and updated. The pre-release sprint pads have been helpful
> > > while
> > > the long-term ones have not worked very well because they quickly
> > > become
> > > unruly, hopelessly confused and soon forgotten (like the bikeshed
> > > pad).
> >
> > This is why I'm trying to "force" a single pad for this. And I'm
> > choosing the pad because I don't want to introduce yet another platform
> > we should follow. If there's a single pad with these tasks, it should be
> > fairly simple for everyone to periodically check, just like email. If
> > there's many pads, it's not as easy.
> >
>
> Yes, a single pad is the only viable option but the question is how to
> manage it. It will require attention to keep it tidy, coherent and current.
> IOW it will be a scab that never heals and needs to be tended to. Would you
> be willing to take on that task?

Nobody specific has to take it up. It's just a matter of having a
standard way of filing them.

> > > > Once the tasks are in place, anyone picking them up would mark that it
> > > > has been picked up and possibly notify everyone else by sending an email
> > > > to devuan-dev@ and update everyone about the task's progress. Each task
> > > > would then have a thread of its own.
> > > >
> > >
> > > Would be nice if it could be that neat. When discussion is required
> > > things
> > > can quickly get messy and confused and as always, soon forgotten.
> >
> > It's always possible to organize a specific meeting if the need arises.
> > For asynchronous discussion, a mailinglist serves quite well.
> >
>
> Unless it's urgent, it might just be easier to do it at our scheduled
> Wednesday rather than trying to find a another time to get together.
> Remember the last time we had to find a time, that's where we ended up
> anyway. Another time might be possible with just 1 or 2 people though.

It is not necessarily a video call. It can also be a conversation on
IRC.

> > > > Depending on whoever thinks a task should be done, and wherever they
> > > > read it, they should put it up on the pad. Whether it's IRC, or a
> > > > Wednesday meeting, or a mailinglist, or d1g, it doesn't matter. What
> > > > matters is that there is a central place. I am not mentioning bugs.do
> > > > here because to me it seems that it might not work well for this issue.
> > > >
> > >
> > > This would work well for those who do not interact with the
> > > community. For
> > > those of us who do, it creates extra work (so that others don't have
> > > to).
> >
> > Can you think of a compromise?
> >
>
> If we tag the items we post on the pad, we'll have a clearer view of how the
> reporting is distributed amongst us and who needs to step it up. I'm not
> pointing fingers here. I am really interested in how that would break down.
> I know that in my years here, I have done a lot of forwarding of issues to
> specific team members. If I pass, it's probably because I don't understand
> the issue well enough to explain it coherently. I'll probably be posting
> lots of links and quotes rather than trying to summarize..

I think you're forgetting about the meeting we had, that KatolaZ has
urged us to have. All of us should be well aware of what we are able to
do with confidence and then just pick up any task that we are confident
to do. If something is outstanding, then ask someone you want for help.
It's common sense.

> > > > Please give me feedback on this so we can see if we can get things
> > > > moving again.
> > > >
> > >
> > > For me the problem is not so much reporting issues but communication
> > > about
> > > changes to the infrastructure that could create issues BEFORE they
> > > are done.
> > > IMO work on essential services deserves a mention that it is going
> > > to happen
> > > and possible discussion about the timing etc. By doing so, those of us
> > > interacting with the community can handle panic if things don't go as
> > > planned. Unilateral unannounced decisions made over the past few
> > > months have
> > > bit us several times (no need to repeat them here) and that should
> > > definitely be avoided in the future.
> >
> > I agree. Again, the mailinglist is a good place to report these kind of
> > things. IRC is not permanent.
> >
>
> Yes, any proposed tinkering should be announced on devuan-dev.
> #devuan-infra is another option. Unless it's something major, no need to
> post to DNG imo.
>
> FYI regarding irc, a lot can be found on Joerg's irc logs or with a grep
> here:
> https://dev1galaxy.org/znclog/?tz=-300&all=y
>
> Thank you rrq for this useful resource which goes back a loooong way thinks
> to the inclusion of past logs from jaromil. I have found it best used for
> more current stuff though because the parameters are limited to 500 results
> iirc (to lazy to fire it up and check).
>
> > > > Thank you.
> > > >
> > > > [0] https://pad.dyne.org/code/#/2/code/edit/dsFabYd7GS165eXdcCb90CSW/
> >