-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal to create a pattern name in the cloud native chapters #257
Comments
Thank you for submitting this issue, @krol3 . I will bring this to the organizer community to review based on regions. We ask that reviews/comments on this issue are read ahead of adding another comment. One may...
|
Hey, thanks for this! Just a question for my understanding: The previous pattern (more or less) was "Cloud Native <City>" as far as I understand. What is the reason to convert "Cloud Native" to "CloudNative" (camelcase)? The ecosystem usually stylises it as "cloud native" (or "Cloud Native" in title case situations like the group names), is there a reason for the departure from this convention? |
Great initiative @krol3 🎉 I think we should definitely use a pattern and apply to all chapters. I'd like to suggest making it a bit more flexible, though. For example, in Belgium currently we're trying to have a Belgian initiative. It's a small country and easy to travel between most big cities, so ideally there should be an option where we don't put the city name but just the country. E.g. CloudNative-BE That shouldn't block having also a specific chapter for a single city if they manage to grow big enough e.g. CloudNative-BE-Ghent Hence, I'd also propose to have the order be: 1) CloudNative 2) Country ISO code 3) City (optional) |
Sounds good, but maybe Cloud Native, for marketing or people that collaborates maybe will be like an error to write CloudNative. Just that change. |
Just a bunch of random thoughts (and I like consistency as much as everyone):
|
This is not applicable to virtual chapter like the Kubernetes Virtual Book Club ? |
I agree with @csantanapr and @tokt while the idea is good, we should take into consideration what could happen to those communities like Cloud Native Canada or Kubernetes Virtual Book Club. Also I prefer Cloud Native instead of CloudNative in the prefix too. |
I agree with the country code. I think it only makes sense if it's a city with a similar name to another major city such as San Jose, USA and San Jose, Costa Rica. Cloud Native Tokyo is pretty self explanatory without the JP in it. |
I think |
'Cloud Native' with a space in mid is better than CloudNative, its so common how everyone writes it everywhere. Specific code can make confusions for a new bie who is entering, or searching for first time in another region - "let say i am based out of india and i want to search a group in USA but I am not sure about which code of which state", so better we have city name as preferences. |
Just adding my opinion here as well: Personally speaking, I'd love to keep the name as it is today: Seriously though, I do see the value of adding the country code to the name, but I'd like to suggest a different approach. IDK if everyone followed the previous discussions, but I really tried to push back when CNCF introduced the common logo to all chapters. I thought, and still think, that this removes all the local culture and personality of the chapters. Having said that, what if we do something as it is done with the KCD's logos? We could then suggest/encourage adding the country flag in the community part of the logo. |
Thanks @krol3 for putting this together! I'm not sure I understand what problem this proposal is trying to address. Expanding on that would help us understand why this is important. To clarify:
Why is it essential? What do we want to achieve? What goal does it serve? Is it for the communities? It's also important to acknowledge the cost of uniformity. As some people expressed above, making these chapters more uniform may also mean they lose their individual appeal to their local communities (which, as far as I understand, is the primary goal of these chapters). This is a valid concern that needs to be addressed and makes clarifying the goal of this proposal even more important. Some uniformity is good. For example, I like that these groups have similar logos. It gives us a sense of belonging to something bigger. But if the goal of these chapters is to serve local communities, it has to be about them. Personally, I wouldn't mind a naming convention, but I don't see the purpose, and I'm also not sure that renaming existing groups outweighs the benefits of a common naming pattern. (I reserve the right to change my mind, though) |
After reading some comments above and thinking some more. We could layout and quantify the different problems to address, and then as a community we can come up with different solutions, because it could be multiple things to do to address the different aspects. We can brake the problem in three areas and go deeper on the problem and quantify it so then we can measure the improvement after the changes/additions
For example one improvement could be a dynamic map of the world, there is a map on this page https://community.cncf.io/chapters/ |
That’s a good one @csantanapr having a similar map as kubestronauts but for the chapters of the CNCF. |
I like the idea of the interactive map! |
For me a global map generates more impact, at least for the chapters that doesn’t have one/more within the same country (like Santo Domingo, San Juan, etc). |
Yeah! It doesn’t apply to the Kubernetes Virtual Book Club. This naming convention proposal is specifically for local chapter cities to improve localization and differentiate them from other cloud-native categories. The proposed naming convention ensures local chapter cities are easier to identify with a consistent pattern. |
I’d like to add my two cents to this proposal to enhance transparency, considering that this could be translated into data. How can we determine whether a group represents a city, region, or country? Since we have different cases, the goal is to make identification easier. This doesn’t necessarily have to be reflected in the group’s title, but we could use category labels to improve clarity. |
@krol3 - regarding the category labels, are you thinking this would be a tag created by Bevy and something people could filter by? As for logo uniqueness - I have updated the terms to where you can add a unique flare around the CNCG logo, as long as the CNCG logo is used and not distorted: https://github.com/cncf/communitygroups/blob/main/assets.md#logos to keep the unity and uniformity. This is already being done well in some instances like: |
@AudMonte01 this is actually a clear example why we need a standard and defined guideline. 1 group is called We also have logos that are totally out of the guideline (2 examples here, but not finger point, just clicked randomly): The only "documentation" on how naming should be handled was in this slack post: https://cloud-native.slack.com/archives/C04KB96TA2X/p1703180725524939, where the example says: We renamed our chapter to Just to wrap-up, I thought that it was part of the guideline how the chapters should be called. But I already saw:
I'd love to have some clarity on that. |
my 2 cents Cloud Native Community City. I think keeping it short is good but I would be hesitant to do Cloud Native City as it is too generic. Adding "Community" makes it clear that it's related to the Community groups. |
Overview
As the Cloud Native ecosystem continues to grow, the establishment of a standardized naming pattern for Cloud Native Chapters is essential. This proposal aims to introduce a consistent, scalable, and intuitive naming convention to improve discoverability, organization, and community engagement across regions.
Proposal
The naming pattern will follow the structure:
CloudNative [CityName] [CountryISOCode]
Examples:
• CloudNative Medellin, CO
• CloudNative Cartagena, CO
• CloudNative San Francisco, US
• CloudNative Bengaluru, IN
• CloudNative Sao Paulo, BR
• CloudNative Rio de Janeiro, BR
The text was updated successfully, but these errors were encountered: