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?

>> > 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.

>> > 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..

>> > 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/
>