Skip to content
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

Resolve "members" section on website #22

Closed
5 tasks done
scottrigby opened this issue Jul 28, 2021 · 23 comments
Closed
5 tasks done

Resolve "members" section on website #22

scottrigby opened this issue Jul 28, 2021 · 23 comments
Assignees
Labels
task Basic task

Comments

@scottrigby
Copy link
Member

scottrigby commented Jul 28, 2021

Problem

Currently the website shows "founding members" because it was the easiest to start, since those are known. It's not yet clarified what "membership" means in the GitOps Working Group and OpenGitOps project.

Steps to resolve

These can be worked on in parallel:

Follow-up

@moshloop
Copy link
Contributor

I think "Founding members" isn't really fair to latecomers or representative of the contribution.

I would suggest just Members, with a randomized scrolling list on the home page, and alphabetical on the members page

We should also have a section for end-users, in which case Advocates and Adopters might be a better wording.

@roberthstrand
Copy link
Member

As someone who has been doing a lot within the working group, I feel that I would like to see that I could add Crayon to a list. I agree with Moshe that just having founding members is a bit unfair, but I don't want the members section to become a big mess.

Advocates and Adopters sounds fair, where Adopters could be very open while Advocates would have some restrictions like being part of meetings, having representatives part of committees, and such.

@todaywasawesome
Copy link
Member

Let's come up with a good way to recognize "current" maintainers.

In the short term, let's get all of those logos added as members and try to grow that because we don't have to figure anything out to do that. So I would encourage opening PRs to add Crayon and others as members and we can get them on the site right away.

@roberthstrand
Copy link
Member

Let's come up with a good way to recognize "current" maintainers.

In the short term, let's get all of those logos added as members and try to grow that because we don't have to figure anything out to do that. So I would encourage opening PRs to add Crayon and others as members and we can get them on the site right away.

I added (first failed, but anywhoo) Crayon in PR #26. Just added it in the members selection and nothing else, I figured that would result in just being part of the members list and not the frontpage.

@scottrigby
Copy link
Member Author

scottrigby commented Aug 13, 2021

@moshloop do you have any bandwidth to help gather logos and permission from orgs the members represent?

This was one of our blockers for adding ALL the company logos.

Secondly, we did agree as a group that there's value in highlighting well known companies who have a unique level of contribution to, and continue to lend wider credibility to this initiative. Exactly how this gets represented on the website is something we intend to iterate on - this was the web design discussion that received very little feedback BTW https://github.com/gitops-working-group/gitops-working-group/issues/159. .

To update this, I believe these can be worked on in parallel:

* note that I'm keeping the current list of things done/to-do in the issue description above, just as a general best practice.

@moshloop
Copy link
Contributor

There is no precedent in any CNCF project for recognizing vendors as maintainers. Contribution ladders are for individuals, not companies.

Regardless, The whole idea of a working group that has a ladder doesn't make sense - A working group is consensus-driven.

Vendors are always treated in a vendor-neutral way, even for projects with a single vendor (Linkerd, OPA) - by giving some vendors a significantly larger marketing stage, above the fold is anything but vendor-neutral.

I am all for highlighting the history, but it is secondary to a vendor-neutral platform, The glaring P1 bug that directly contravenes the Charter and CNCF principles need to be fixed now - it can't wait until a consensus-driven decision is made around a secondary concern that may never be reached.

@scottrigby If companies want to be on the website, then they should submit a PR

@roberthstrand
Copy link
Member

There is no precedent in any CNCF project for recognizing vendors as maintainers. Contribution ladders are for individuals, not companies.

Regardless, The whole idea of a working group that has a ladder doesn't make sense - A working group is consensus-driven.

Vendors are always treated in a vendor-neutral way, even for projects with a single vendor (Linkerd, OPA) - by giving some vendors a significantly larger marketing stage, above the fold is anything but vendor-neutral.

I am all for highlighting the history, but it is secondary to a vendor-neutral platform, The glaring P1 bug that directly contravenes the Charter and CNCF principles need to be fixed now - it can't wait until a consensus-driven decision is made around a secondary concern that may never be reached.

@scottrigby If companies want to be on the website, then they should submit a PR

I agree with the sentiment, but this is also not the working group website, but the project website. Most projects have vendors on their homepage to show that it's supported by well known actors.

Maybe this would resolved by highlighting a certain number of the members on the home page selected at random from the greater list, but also have the current (and then some) companies highlighted as "backed up by" or whatever we call it. For that list, one would probably set some expectations for what entails. Many of the current companies that are on the home page today are not only participants in the working group but also create much content in regards to GitOps, create tools for it, enable it on their platforms, etc.

This would make it easier for people that use or follow the GitOps principles to add themselves to the list of members, while companies that invest time and effort into OpenGitOps get a little back for donating their time and people to the cause. At the same time, it would be vendor neutral because anyone could get to that status if they want to.

What do folks think?

@moshloop
Copy link
Contributor

Most projects have vendors on their homepage to show that it's supported by well-known actors.

This is fine, but it is a flat alphabetical list, with no "featured" vendors - even for projects with a single vendor.

Many of the current companies that are on the home page today are not only participants in the working group but also create much content in regards to GitOps, create tools for it, enable it on their platforms, etc.

The same can be said for many companies not on that list, You can distinguish between end-users/adopters and advocates/vendors but you cannot create a hierarchy within those sets

@roberthstrand
Copy link
Member

Many of the current companies that are on the home page today are not only participants in the working group but also create much content in regards to GitOps, create tools for it, enable it on their platforms, etc.

The same can be said for many companies not on that list, You can distinguish between end-users/adopters and advocates/vendors but you cannot create a hierarchy within those sets

I agree.

I for one think that it's great to showcase well known actors that are helping us create this project, by helping us run the working group through letting employees prioritise it. This list could easily be expanded, of course, but then I would prefer to have some prerequisites for that. Thinks like, having employees being part of committees, running public events on the topic, create content and buzz from official social media accounts. Things that makes promotes GitOps, that would actually make sense for an advocates list.

Having a list where everyone can add their company is a non-brainer, and perhaps this list will have some random names pulled to the home page. This means reviewing and approving PR's would basically just mean checking that the link they are adding aren't bogus, then approve it.

I think this is fair, both to people that use GitOps and are invested in it but also to the companies that spend time and money on this.

Maybe at a point we could have pages for each member, where one could add inn what they do and how they use GitOps? A lot can be done there as well.

@moshloop
Copy link
Contributor

I for one think that it's great to showcase well-known actors that are helping us create this project,

This is almost impossible to do in a vendor-neutral way, who gets to set the criteria? Who evaluates the criteria initially and on an ongoing basis? Highlighting what each vendor is doing by linking to posts, resources, products, conferences are fine but this WG is not allowed by its own charter to say one vendor is contributing more than another.

vmware is listed last, on goharbor.io despite the fact they contribute(d) more than all the other partners combined.

@roberthstrand
Copy link
Member

I for one think that it's great to showcase well-known actors that are helping us create this project,

This is almost impossible to do in a vendor-neutral way, who gets to set the criteria? Who evaluates the criteria initially and on an ongoing basis? Highlighting what each vendor is doing by linking to posts, resources, products, conferences are fine but this WG is not allowed by its own charter to say one vendor is contributing more than another.

vmware is listed last, on goharbor.io despite the fact they contribute(d) more than all the other partners combined.

I think you are missing my point, or I am not making myself clear enough because we are talking about the exact same thing.

I never meant that we order advocates based on contributions, but that to get to that list one would have to actually be advocates. Meaning, contribute to the working group, promote GitOps as a concept, or whatever we feel should be the criteria. This is something we could easily do as a group, and as long it's properly documented there would be no issue in determining who is a contributor/advocate/partner or whatever we call it.

Besides that, we are discussing how to display this on the website. For which I am suggesting that we show the advocates/contributors like we do now, but also add a taste of what the other list has by picking random names to display. The entire list will then be linked to, like it is now, where everyone will be present. Everything in alphabetical order, just like it is now, but in two lists - Advocates and Adopters.

@moshloop
Copy link
Contributor

The problem is having 2 different lists with 1 receiving more marketing face time than the other - Vendor neutrality means vendors receive equal marketing time.

It's fine to have a bar to be considered an advocate to eliminate spam, but it is a single bar that once met, all advocates are treated the same.

It's fine to have a bar and graduation criteria for individual projects based on objective criteria, but not for vendors.

@roberthstrand
Copy link
Member

Again, maybe I am not making myself clear. I think this is getting overthought, somewhat.

Unlike many other projects, which are tools or toolsets, it takes very little for someone to be regarded as an adopter as there are several tools for GitOps. This is just the front page, and displaying every single member there wouldn't do any good. At that point, we could just add an introduction at the top of the members page and set that as the front page.

Giving advocates more marketing? Well, shouldn't that be the case? If the companies are behind it, help develop it, help promote it, shouldn't they be? If anyone want to be an advocate, they can. There is literally nothing stopping them, so I don't get why this is a bad thing. Actually, the more I think of it, it can get more companies involved. Isn't that what we want?

If we add one list where the companies that are part of the working group and help out the project is on, sort it alphabetically and put them on the front page, that is vendor neutral. If we don't do that with adopters that doesn't mean it's not vendor neutral, it is just practical.

What we are discussing here is purely how the members list should be structure and how members should be represented on the home page. Not projects, not if they are vendors or not, just how we deal with OpenGitOps members. I agree that we shouldn't raise certain companies status by purely displaying them on the front page, which is something we have discussed in meetings. That has been fine for now and as a start, especially since these companies are (almost) mainly who is actually attending these meetings and help push things forward. There are others beside the ones that are on the front page right now, and I think we need to add these as well. I am not saying this because the company I work for would be in that category, but because it actually makes sense.

Adding all advocates and adopters to the first page, I think that might work now but what in a year? What about two years ahead? Maybe this becomes the industry standard that everyone uses and all the sudden we have 300 names on the list? That doesn't scale, so why not just start of by keeping the extended list on the members page that is linked to in all the right places and keep the page clean, highlighting the people that spend their time for the cause?

@moshloop
Copy link
Contributor

moshloop commented Aug 15, 2021

I agree advocates and adopters should be split, my concern is splitting the advocates into 2 distinct groups, with 1 group receiving more marketing than the other:

If we add one list where the companies that are part of the working group and help out the project is on, sort it alphabetically and put them on the front page, that is vendor neutral

That is what I did with #16,

There are others beside the ones that are on the front page right now, and I think we need to add these as well.

The PR has been open for 19 days.

why not just start of by keeping the extended list on the members page that is linked to in all the right places and keep the page clean, highlighting the people that spend their time for the cause?

That is not vendor-neutral, who gets to decide what warrants enough time to justify being highlighted? The existing 6 vendors ?

What about two years ahead?

That can be handled in 2 years

@roberthstrand
Copy link
Member

Again, like I said multiple times, I agree. I am only talking about this two lists, advocates and adopters. I am not suggesting splitting advocates into a list of prioritized companies. I never have, I have only explained why it's like that at the moment. The reason why your PR has been open for 19 days is for two reasons. Firstly, you didn't want to update the pull request temporarily as the per the maintainers requests while we figured things out, and secondly because this is a discussion that needed to happen. We're having it now, and I am agreeing with you. Which I have, all along.

I am not saying:

  • Create a list of highlighted members on the front page
  • Split the advocates list into two groups
  • Give one group of companies more marketing

What I am saying is that I think we should:

  • Add some sort of guidelines to what advocate means
  • Add those companies to the front page
  • Let anyone add themselves to the adopters list
  • Have the entire list on the members page, linked from the front page

No matter how you look at it, this is not up to you and me. Right now, we just need to voice our opinion, give others the chance to voice their, and then either agree here or talk about it in the meetings.

@scottrigby
Copy link
Member Author

Update, following up about this with @amye today, here is the plan for after KubeCon NA 2021 (which we're all preparing for next week):

We've temporarily addressed this by sorting all companies on the community page in alphabetical order (https://opengitops.dev/community), and we already allow orgs to list themselves by opening a PR on that page (example, #26).

But we can go some distance further than that ourselves already, even without explicit permission by each company the other members represent to add their logos yet, by using a generic logo placeholder. This is just a task that needs to be done, and which anyone in the community is free to start as a PR.

But how to list? This has been on hold because no one had officially defined what membership actually is (see gitops-working-group/gitops-working-group#38).

Let's just keep it simple and be sure to reflect the current reality, while avoiding anything that could appear bias for specific companies. We are in fact vendor-neutral! The reality is we have these user groups already self-defined, and therefore already opted-into for listing purposes:

  • gitops working group member orgs
  • founding member orgs
  • interested parties

Let's just add a members/community link on the homepage (whether the homepage adds a handful in random order somehow, or in some other way makes clear how many orgs are involved), just link to that standalone page which lists those 3 sections.

After being listed, we can put more effort into publicizing an invite to each org to open a PR to add their logo, since we know that can be a different process per company.

Sound OK?

@moshloop
Copy link
Contributor

moshloop commented Oct 6, 2021

whether the homepage adds a handful in random order somehow, or in some other way makes clear how many orgs are involved

To be clear, you are suggesting:
a) remove the list of founding members from the home page
b) update the community page with 3 equal categories
c) optionally add a random selection to the home page that selects from all 3 categories (not randomly from each category)

@scottrigby
Copy link
Member Author

@moshloop correct. The notable differences between this and previous convos are:

  1. we now have a definition for membership (at this point, just a reflection of the reality, subject to change if this gets defined differently in future). Thanks to @amye for helping us choose this definition, as that's what we had been missing.
  2. Since we do have that defined now, it is sufficient to clarify those all on the same page. There is no need to highlight only one on the homepage.

For optional C above, that was just something that was mentioned. Maybe it would be more impactful to show all of the logos we have in a small "cloud" formation on the home page. This is something that can be discussed and designed.

Thank you Moshe for continuing to raise this ❤️

@lloydchang
Copy link
Contributor

@scottrigby wrote:

Since we do have that defined now

I searched for membership this repository, and I don't see where the definition is.

All search results at https://github.com/open-gitops/website/search?q=membership&type=issues point me back here at #22 and related #16 which don't clarifying the definition of membership.

@scottrigby Would you kindly post the verbatim definition of membership here?

Without the verbatim definition here in #22, the current GitHub search result for membership is just unhelpful.

Thank you!

@lloydchang
Copy link
Contributor

@amye @moshloop @jlbutler @murillodigital @roberthstrand @scottrigby @todaywasawesome When your time permits, would you kindly review #43?

Since OpenGitOps is principle-led, move principles toward the top of the web page. Additionally, move testimonials and founding members toward the bottom of the web page.

Thank you!

@scottrigby
Copy link
Member Author

PS here is the current link for interested parties https://github.com/cncf/tag-app-delivery/blob/master/gitops-wg/interested-parties.md

@lloydchang
Copy link
Contributor

Relates to open-gitops/project#34 (comment)

@scottrigby
Copy link
Member Author

I'm going to close this as the members section is now generally resolved per #22 (comment) through merging #16.

Another fun note: as part of the closing session of GitOpsCon this year, we will be making a much more clear path for folks to know how to be part of OpenGitOps, what "membership" means, etc https://sched.co/zrr9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
task Basic task
Projects
None yet
Development

No branches or pull requests

6 participants