Idea: Commercial Support / Vendors

Tl;dr - Demo Site -

Hey Everyone,

Since getting elected to the board a little less than two years ago I really wanted to revitalize the commercial support program we used to have. There’s not enough of us doing forum support, and even when there is, there’s some questions (such as “why is this slow”) that volunteers just don’t have the availability to deep dive into and do it justice.

So after up and running, I’m thinking of trying to get up and running. The previous one (Jenkins : Commercial Support) is very very out of date, and very free form.

What kinds of things do you think we should track? I want to make things as machine friendly as possible.

I’m really just spitballing here and would love some ideas and feedback.

  • Name
  • Logo
  • Url
  • Timezone/24hours?
  • Features/Offers
    • commercial support?
    • custom products?
    • training/best practices?
    • certification?

maybe something involving how they contribute/give back to the community as a whole?

What else do you think is useful?


I like all those items and am very much in favor of it.

Is your intent with as a separate domain that it would require additional permissions to make changes there, different from placing that type of information onto a topic here on or is there something else that prompts you to use a separate domain?

Since you’re talking about data, would it be better to place that information under and store the data values there, then render them on the site? That would allow curated commits to the directory storing the data like we have with governance changes and security changes on today.

1 Like

Small sites are easier to manage. Have different tech stacks as needed. Less overwhelming and old.

Right now is kinda old tech stack, which makes it very ackward to develop as it requires ruby and node, and building templates in a syntax nothing else in Jenkins is using. Etc. is so much slower than plugins and stories which takes full advantage of httpsw and cdn hashing and stuff.

Honestly there’s nothing gained from having everything in a single site, just makes it bigger and harder to manage.

As for management. PRs is what I’m thinking. Probably with WYSIWYG if I get netlifycms working reliable.

Note core has been doing the same thing for years. Instead of a huge project that a change could break everything, extract things into smaller more agile parts, so lower risk changes and easier to expirament

But honestly that’s not the important thing. Right now it’s what the data looks like, then later where the data should live

1 Like

Out of curiosity, what would be your preferred stack that’s at least as well known among Jenkins contributors? Using Jelly or Groovy would check the “familiarity” box, but seem like a terrible idea.

My vote is gatsby as we’ve used it for a couple projects now, fast and reliable and we have tooling to create the header/footer/etc. React is pretty much just html with a bit extra. At least the majority of tweaks a site like this would need. Since my intention is to have the data in yaml or something i’m not overly concerned. It means it could go directly into if needed.

As far as I can tell, and (frontend), both very recently. I don’t see how that compares favorably in terms of general contributor familiarity or similarity with Jenkins.

(An argument can be made that awestruct is basically dead, so perhaps not a great choice for a new project from that POV, but that’s not what you’re pointing out as a weakness.)

we moved over plugins from nextjs to gatsby like 2019, but again, not the point of this post. Right now i’m trying to figure out what information needs to be collected, its not hard to change after the fact, but i’d like to get some feedback early on.

Okay, I’ve contacted all the companies from the old commercial support pages. A bunch no longer exist, and others I couldn’t find a working contact form/email address for, but hopefully this leads to more information.

I’m imagining some sort of UI like Zillow or something that lets you filter for what you want.

I really like “maybe something involving how they contribute/give back to the community as a whole?”
If you are to put their names somewhere I think it’s fair to expect they’ll bo contributing one way or another. And I believe it matters to others, potential customers

I like all of these ideas and think it would be a great way to track & interact more with the community as a whole.

Would it be possible/helpful to track things like the number of plugins adopted or maintained? The number of pull requests merged could fall into a similar category of data.

Would there be a direct connection to the respective vendor support page? It looks as though the various venders could be separated by offerings or location(s), this could help navigating the page.

Other than that, training could be different levels/skills (getting started, using, maintaining).

1 Like

Oh wow thanks so much for this feedback.

I like that a lot. Gimme some time on how to do it, but we have a bunch of the metadata from GitHub - jenkins-infra/repository-permissions-updater: Artifactory permissions synchronization tool and data set so we could do it, just gotta figure out how to map.

Absolutely. When trying to reach out to all the past vendors I found it really frustrating to figure out how to contact people. I’m thinking of either a direct email, or a url.

Yea, I like that for filtering. Though don’t really know how to represent that yet…

Of course, no worries at all, and take the time you need.

In regards to the direct contact link/url, it might be something that could be collaborated on with the vendors themselves. They may have a specific address that users could direct their queries to for proper tracking. Additionally, I would be hesitant to set time frame expectations for support due to the different SLAs that the vendors may have. When I had worked support previously, some offered 24 hours, some offered assistance within 48 hours, so it’s very dependent on the organization. That could also be broken down/categorized if it came down to it.

I’m not sure what the best way to represent the training offerings would be, but I think getting some perspective/insight from the vendor might help determine what that might look like. They may have these distinctions already and if that’s the case, they could even be used as a basis for determining what sort of groups would exist.

A direct link to the vendor help sites/knowledge base(s) would be beneficial, as the existing help/support information could answer some questions as well. In my previous life as a support engineer, the help/kbase would be the first stop, but would allow the user to reach out directly to work with someone from there. Providing the resources will reaffirm confidence, create more options for the user(s) to get assistance, and remove some of the inherent frustration/stress that comes with something not working as expected.

okay, here’s what I’m thinking so far. does this cover everything we talked about? going to try and prototype some UI this weekend.

cat src/vendors/ozguryazilim.yaml
name: Özgür Yazılım
# Landing page for support?
# Later we'll embed logos into the site so we don't ever get 404s
# for timezone listing
# I don't know how to record this yet
  - name: istanbul
    timezone: +0300
  - name: ankara
    timezone: +0300
  - en
  support: true
  custom_builds: false
  training: true
  certifications: false
# should be ldap usernames so we can look up plugins as needed
  - kmartens27

@MarkEWaite @Jmm feel free to do one for cloudbees too so i have more sample data?

Super initial prototype version -

1 Like

The prototype looks great from my perspective! I like the offerings being listed below w/checkmarks, that makes it nice and clear what can be found.

A solid start, although I wonder how useful the filtering is going to be. How many entries do we expect?

I thought the logo was dirt on my screen :sweat_smile: White on transparent background on white doesn’t look great. Is the expectation that vendors provide compatible logos, or should the site handle these better?

little of A, little of B

For my prototype i just pulled the url from the site. I didn’t realize it was a banner, the text was transparent on my browser. Gatsby lets me resize and rescale images really easily, but I didn’t really want to do too much gatsby stuff for a prototype.

I’ll hopefully get to play with the site a bit more this weekend

We had like 10 in the old system, but I don’t know how locked down that page in confluence was. I don’t know though, which is why i’m asking for feedback. Could always hide the “advanced” filters section and show it on click or something.

Here’s my attempt (not vetted with anyone yet, just using public locations):

cat src/vendors/cloudbees.yaml
name: CloudBees
# Landing page for support?
# Later we'll embed logos into the site so we don't ever get 404s
# for timezone listing
# I don't know how to record this yet
  - name: New York
    timezone: -0400
  - name: San Francisco
    timezone: -0700
  - name: London
    timezone: +0100
  - name: Paris
    timezone: +0100
  - name: Sydney
    timezone: +1000
  - name: New Delhi
    timezone: +0530
  - de
  - en
  - es
  - fr
  support: true
  custom_builds: false
  training: true
  certifications: true
# should be ldap usernames so we can look up plugins as needed
  - abayer
  - alecharp
  - amuniz
  - aneveux
  - basil
  - batmat
  - carroll
  - danielbeck
  - dduportal
  - jglick
  - kerogers
  - kmartens27
  - markewaite
  - mikecirioli
  - olamy
  - rarabaolaza
  - richbg
  - rsandell
  - teilo
  - twasyl
  - vlatombe
  - wfollonier