GitLab for the engagement team

[Carlos Soriano <csoriano gnome org>]

Hey all,

Since I was not subscribed before, I cannot reply to the main GitLab thread. I want to put here the advantages and disadvantages I see of using GitLab for the engagement team.

I believe using GitLab for the engagement team will help improve some of the weakest parts. I focused on the interaction of the engagement team and the rest of the community, the tracking of dates, and assignee to tasks.

I think one of the biggest issues has been the interaction with the rest of the community . The engagement team is mostly a mailing list and IRC, but it's not close to any other part of the developer community and I have the feeling it didn't work as much as it could. Seems the developers ended up not interacting much with the engagement team, and the other way around. With GitLab you will be using the same infrastructure as the rest of the community and the developers can take a look what you are doing, how do you work, and what things have been happening to take as an example. Also, developers will be used to the infrastructure and will be more likely to interact with the engagement team. You can see this change already happened in the short live of the engagement project in GitLab.

For the tracking of dates, if I'm not mistaken it hasn't been done, and in my personal case with managing SWAG it already failed once. Not only that, but since there is not a comfortable infrastructure where to see what's going on, nobody knew I was going to fail to send in time the SWAG. I imagine something similar happens with publishing tweets or other social media for events.

Another issue is that since there is no clear way to have an assignee to a task (afaik), the task can be forgotten or missed and potentially the rest of the engagement team won't know who to ping to know the status of the task. This happened also for me with the SWAG, since probably not many people knew I had to send it.

In general, I think the current setup of just emails and irc doesn't work well, so I think some kind of tracking will be helpful, and if it can be close to the rest of the community, even better.

Now, I can see two disadvantages. One is that GitLab it's a technical tool, and because of that the UI could be nice but it's technical. Second is that it shouldn't feel like paperwork, it really shouldn't.

The good thing is that almost everything can be automated, so I spend some time today in creating good issues templates so you don't have to do any paperwork. I believe the only paperwork the engagement team would have to do is to close an issue when it's done.

To try to fix the technical barrier, I created some documentation with pictures and shortcuts links for common tasks. Take a look at the readme and specially to the wiki.

Let me know what you think; and feel free to ask if you have any question. I'll join the meeting today too in case you want to discuss it.

Best
--
Carlos Soriano
GNOME Foundation
Treasurer, Board of Directors