The gradual roll out of this change started with a blog post[0] and included in-app notifications for the owners of impacted groups on GitLab.com.
If the group owner did not log in during the in-app notification period, they were then emailed (the email you received today) notifying that the group was impacted.
I don't know that it's a great plan to do a blogpost and in-app notification as the first round of reminders and email on the day of the change. Both the blogpost and in-app notification requires you to explicitly go on GitLab and see there's a problem. Maybe there's a reason to avoid it, but emailing from the get-go seems like it is the right move for transparency and not rug-pulling.
Wouldn’t it make more sense to email them before they were impacted instead of when they were impacted? What’s the point of gradual roll out that requires I read your blog etc. An email that says “You have 60 days to X” is a lot more effective than one that says “60 days ago we made a blog post letting you know, and now you’re f’d.”
Look they announced it publicly posted right in the back of the file cabinet in the basement behind the warning rabid tigers sign.
Here's a question for Gitlab: "Why did you require me to give you an email address to sign up?"
The answer to that question means there is no explaining why they didn't use it first, and followed up with at least a couple updates along the way. This is exactly what the address exists on thier db for.
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
> If the group owner did not log in during the in-app notification period, they were then emailed (the email you received today) notifying that the group was impacted.
I think there is a glitch in your mail or something else is going wrong. I'm currently not in any groups and still got an e-mail telling me that my top level group (starting with 5060) has reached the 5 members limit. Searching for the group also doesn't yield any results whatsoever.
i got an email that the limit in one of my groups is reached.
i just logged in and there is no indication of any limit.
i had to step through every group to find out where the limit was reached.
turns out that there was one group that had two sub groups which added up to 5 members. at the group overview this is listed as "two" (for the two subgroups). it would be very helpful if the group overview (https://gitlab.com/dashboard/groups) would list the total number of people as well as flag every group where the limit is reached or crossed.
but, you say the limit is 5 people. in this group there are exactly 5 people, yet the warning claims 'Your top-level group is over the 5 user limit and has been placed in a read-only state.'
how can that be? 5 is more than 5?
it doesn't matter in my case because this is an old project no longer worked on, so read only is fine, and there is no need to act, but i think you need to work on your system because i am sure there will be more cases like that.
lastly i want to add that while that limit is fine for small businesses, it is an absolute disaster for FOSS projects. FOSS projects don't have the funding to pay for your service, so they won't. their only option is to leave. if any of my projects get any traction then i have no choice but to go look for a more FOSS friendly service. i thought gitlab was that, i wanted to make a point against github and support their most likely competitor by drawing attention to you.
gitlab really does not gain anything by enforcing this limit for FOSS projects. FOSS projects often have many members that are not very active. a busy startup with 5 members probably creates the same activity and uses the same resources as a FOSS project with 50 members because most of those 50 members rarely contribute to the project.
or instead of limiting members, limit how often the more expensive resources are used. like limiting how often the CI is running.
i urge you to consider to allow a higher limit for groups that only have projects that use a FOSS license.
thanks, i wasn't aware of this. that's even more than i was looking for, except, the no commercial activity rule seems a bit limiting:
Not seek profit: An organization can accept donations to sustain its work, but it can’t seek to make a profit by selling services, by charging for enhancements or add-ons, or by other means.
so i can't sell services to sustain the project? there is a large difference between earning some money to help fund the project, making barely enough to be able to work on the project fulltime and actually making enough of a profit to afford commercial services.
if i am employed and work on a FOSS project on work time, then i am not selling any services, nor am i making a profit.
if i do exactly the same but as a contractor, then i am selling a service.
you may want to elaborate how you interpret and verify this rule.
also i'd rather have less free services but a more liberal allowance on commercial activity. like a regular free account but without the user limit.
user limits are very frustrating because they prevent me from managing all potential contributors, even if they are not very active.
The gradual roll out of this change started with a blog post[0] and included in-app notifications for the owners of impacted groups on GitLab.com.
If the group owner did not log in during the in-app notification period, they were then emailed (the email you received today) notifying that the group was impacted.
[0] - https://about.gitlab.com/blog/2022/03/24/efficient-free-tier...