Re: [Tiki-devel] About the roundtable meetings...

Thanks Marc to bring this topic up.
Thanks Bernard to taking the responsibility for organising the meetings 
since quite a while.

I am in a different yet similar situation and experience various types 
of scheduling in various groups and organisations.

I appreciate the effort to give every developer and other members the 
opportunity to participate as often as possible and thus to broker the 
time and dates. Although for me the current process leaves me behind for 
that I am actually nearly never able make it to attend.

If we had one or two days in a month, one fix and one optionally 
flexible, *just for example:*

* 1st week Monday 14:00 EDT = 19:00 UTC - jour fix.
    plus
* 3rd week flexible brokering with plugin convene.

... I am very sure that I could attempt quite regular. I really miss the 
roundtable meetings and would like to contribute.

Anyway I have so many different appointments during the week, that in 
the current Tiki scheduling process I neither can plan longterm, nor 
fiddle in between short term emergencies.

Imho we need at least one fixed day per month.
I'd rather set my clock regularly to a night meeting, than regularly 
broker short term a regular meeting until short before the actual event.

*My suggestion:*

Let's set one monthly jour fix roundtable, that fits well for North 
America (east coast!), but is not insane for Europe/Africa ... not 
forgetting Gary in Asia. The day should meet the requirements of the 
most active developers and project admins and can be adjusted every year.

I am fine with early morning or late evening.
This would give me (and others) the opportunity to block most meetings 
for 6 or 12 month in advance.

Let's optionally keep another monthly flexible broker roundtable for all 
members who cannot attent the jour fix or who want to regularly arrange 
additional meetings and respect other timezones and workdays.

This flexible second date could aswell be used for follow up meeting 
after the jour fix.

Best regards,
Torsten


Am 23.04.23 um 01:02 schrieb Marc Laporte:
> Hello Bernard,
>
> I would love to participate more often, and I have many answers to 
> questions that people will ask (ex.: what is roadmap for feature 
> XYZ?). However, as a CEO of a growing company, and a volunteer in 
> various organizations, my schedule fills up quickly. I am always 
> available for emergencies, but I refuse to be an enabler of an 
> inefficient process. And thus, I won't cancel/move my other meetings 
> because the roundtable was confirmed a few days before it is held.
>
> It takes less time (FOR EVERYONE) to plan a meeting in 3 months than 
> in 3 weeks because almost everyone is available if you book them 3 
> months ahead of time, assuming you pick a time appropriate for all 
> timezones of your target audience. But if you book people 3 weeks 
> before, you need to use a tool like https://doc.tiki.org/PluginConvene 
> and everyone needs to invest more time. Block all potential meeting 
> dates, vote, then, stay informed of when meeting is confirmed, and 
> free up other slots.
>
> As you now, I manage a team. I want my colleagues to participate to 
> these events. They can learn, and they can share. But as a company 
> policy, we don't impose work schedules. Team members make their own 
> schedule, and they adapt for the few times we have team meetings. 
> Thus, late announcements of monthly round tables make it that we don't 
> even convey that there will be a meeting.
>
> If you plan the meetings 12 months ahead of time, they can be useful 
> to help organize other things, like branching dates or release dates. 
> We just picked the dates for the branching and release of Tiki 26.0, 
> and if we knew when the next roundtable was, it would been taken into 
> consideration.
>
> If you plan the meetings months ahead of time, we can permanently have 
> a banner on all *.tiki.org sites which says: "Next community meeting 
> in 22 days. Click here to add to your calendar, click here for a 
> browser reminder 1 hour before the meeting, etc."
>
> So planning monthly meetings on short notice:
> * Takes more time from everybody (organizers and participants)
> * Reduces participation of existing community
> * Reduces the opportunity for synergistic scheduling * Reduces the 
> opportunity for potential new community members to know about it, and 
> join.
>
> So my recommendation is to pick the same day/time every month and 
> schedule/announce them 12 months in advance. So everyone can block 
> those times in their schedule. You can look at past votes to see what 
> are general preferences. I guarantee that this will have a huge impact.
>
> It is very similar to when we didn't have scheduled Tiki releases. By 
> announcing a release schedule, the whole community could self-organize 
> to fit their individual plans within a larger community plan: 
> https://tiki.org/Tiki-Versions
>
> Here is an associated concept: https://en.wikipedia.org/wiki/Stigmergy
>
>
> As an example: Jitsi, and I am copy-pasting their info:
> ----
> Recording of Jitsi's bi-weekly community call. This is where the Jitsi 
> team shares their latest development status and plans. Community 
> developers can ask about issues and make requests directly with the 
> Jitsi development team.
>
> Join us every-other Monday at 10:30 Central US - 
> https://meet.jit.si/TheCall.
> Visit jitsi.org for more details.
> ----
> Mautic has something similar.
>
> FYI, we have some team members assigned to work on this:
> https://meetingfacilitator.dev4.evoludata.com/
>
> Best regards,
>
> Marc
>
>
>
> On Thu, 20 Apr 2023 10:51:24 +0300 Tiki developers 
> [email protected] said
>
>> Hello All,
>> We have a TRM today at 13UTC and I would like to share some thoughts…
>> TRM participation is down to a point that I wonder if there is any 
>> interest
>> to keep and maintain them…
>> End of 2022… ahem let’s skip to 2023. 01 few people (fosdem meeting) 
>> 02 was cancelled 03 was only Gary and me 04 … not a lot of people 
>> express interest to join
>> I wrote this because I hope we can keep a formal regular meeting between
>> members and new comers of the Tiki project.
>> Those meetings still have interest for:
>> - Announcement/status of things to come: release process, change of
>> technology discussion (bs5, PHP8, etc) - Demonstration of new 
>> additions in Tiki or better way to use the existing - Human/social 
>> relations between members of the community
>> ——
>> In the past they had an interest for: - Discuss revamp or addition of 
>> stuff - Vote on a decision - Tiki.o websites decisions or changes - 
>> Tiki Association
>> Those are happening outside of the TRM since a while. It allowed to 
>> have more
>> topics filling the TRM planning.
>> ——
>> With fewer point of interest, it is very hard to maintain TRM if the 
>> meetings
>> are not regularly organized and offer interesting topics every month
>> Announcements Having 2 to 4 announcements per year for release status 
>> or branching is not
>> enough to fill the TRM. (Tiki25.0 was the last release discussion Nov 
>> 2022) Technology addition or change requires volunteering from 
>> developers or people
>> involved and having the knowledge. (not happening)
>> Demonstrations Requires volunteering from developers or people that 
>> have things to show to
>> the other. (Volunteers are rare and it can’t be always the same 
>> members) Personally I think that with a continuous flow of additions 
>> in Tiki we should
>> have 2 TRM per month. A lot of stuff is added, very few knows and
>> documentation with samples/usecases to attract people on Tiki don’t 
>> follow
>> 🥴
>> Human/social relations between members of the community While 
>> essential in my mind and almost the reason I keep coming, this is not
>> enough…
>> See the usual suspect (stolen from JonnyB I admit) in a few hours, 
>> Bernard
>
>
>
>
> _______________________________________________
> TikiWiki-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel