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

Marc Laporte <[email protected]>
Newsgroups gmane.comp.cms.tiki.devel
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.