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.
I like all those items and am very much in favor of it.
Is your intent with vendors.jenkins.io 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 community.jenkins.io 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 www.jenkins.io and store the data values there, then render them on the www.jenkins.io site? That would allow curated commits to the directory storing the data like we have with governance changes and security changes on www.jenkins.io today.
Small sites are easier to manage. Have different tech stacks as needed. Less overwhelming and old.
Right now jenkins.io 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. Jenkins.io 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
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 jenkins.io if needed.
As far as I can tell, stories.j.io and plugins.j.io (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 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).
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?
url: https://www.ozguryazilim.com.tr/en/
# Later we'll embed logos into the site so we don't ever get 404s
logo: https://www.ozguryazilim.com.tr/wp-content/themes/ozguryazilimv4/dist/assets/img/ozguryazilim_logo.png
# for timezone listing
# I don't know how to record this yet
locations:
- name: istanbul
timezone: +0300
- name: ankara
timezone: +0300
languages:
- en
features:
support: true
custom_builds: false
training: true
certifications: false
# should be ldap usernames so we can look up plugins as needed
community_members:
- kmartens27
@MarkEWaite@Jmm feel free to do one for cloudbees too so i have more sample data?
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 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?
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?
url: https://support.cloudbees.com
# Later we'll embed logos into the site so we don't ever get 404s
logo: https://images.ctfassets.net/vtn4rfaw6n2j/6oRZhUL5vhhrH8XKbpyk4Q/fd6004275d63bd2436d2680a196e733a/cb-logo.svg
# for timezone listing
# I don't know how to record this yet
locations:
- 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
languages:
- de
- en
- es
- fr
features:
support: true
custom_builds: false
training: true
certifications: true
# should be ldap usernames so we can look up plugins as needed
community_members:
- abayer
- alecharp
- amuniz
- aneveux
- basil
- batmat
- carroll
- danielbeck
- dduportal
- jglick
- kerogers
- kmartens27
- markewaite
- mikecirioli
- olamy
- rarabaolaza
- richbg
- rsandell
- teilo
- twasyl
- vlatombe
- wfollonier
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?