Valve Developer Community:Proposals

From Valve Developer Community
Jump to navigation Jump to search
Icon-message-48px.png
This is the discussion page of Valve Developer Community:Proposals. To add a comment, use the Edit button near the headline of the appropriate section. To create a new section, you can use the Add topic button at the top of this page.
Comments on talk pages should be signed with "~~~~", which will be converted into your signature and a timestamp.

Overall community centralization project

The idea of a "central location to discuss formatting changes" was discussed on the Valve Developer Community discussion page. This separate "Proposals" page is intended to serve that purpose, although as I said in the aforementioned discussion, I think there's a deeper issue with users not having any way to know of active discussions in the community outside of looking at recent changes. You could see some of the changes I've experimented with to try to resolve this issue in User:Blixibon/Centralized community proposals, which includes the "Current ongoing discussions" box at the top of this page.

Because my proposals themselves are formatting changes affecting other areas of the wiki, I'm going to use the initial topic on this page to consolidate discussion about what I've proposed.

Here's a checklist of what I've done so far and am currently planning to do:

I received positive feedback from one other user in the aforementioned discussion, although I would prefer to have a broader or more solid consensus before changing existing (or at least the most prominent) articles. I'm also taking this slowly due to other ongoing changes to the wiki's landscape (e.g. the removal of Template:MultiPage among other language-related things), and I don't want to distract from or interfere with that if I change existing articles.

Please leave a response if you object to, support, or have any other comments on these changes. --Blixibon (talk) 17:09, 11 July 2024 (PDT)

Sorting out navboxes

There was a time when a lot of navboxes were spawned. There's huge navboxes like {{Sdktools}}, there's arguable navboxes (as to their rules of inclusion) like {{Half-Life games}} (especially when viewed with both third-party and cancelled content).

There's... difficult to parse, {{Branch-navbox}}.

And there's very redundant, very tiny navboxes for these many splinters of gamedev history, such as:

I am not saying these are all bad, need to be removed, etc. I am saying, that they need to be reviewed, some reworked, some updated, some cleaned up, and some, well, most likely removed.

Reminder that the {{navbox}} template itself warns against excessive use. They're not a piece of automatic patchwork; they shouldn't just be spawned because they can be justified.

Some of them (DOD, Taito) are so miniscule there's no navigation to really speak of. The few pages that use them, all can include their links in "See also".

Orange Box one looks messy because of its notice. And kind of matches the previous point (navigating in between three titles, essentially).

Xash is 2 working links and 5 redlinks.

I propose a discussion about them, some of it is broad stuff, some we can probably decide right on the spot.

More examples of needing work, can be brought in during the discussion. Cvoxalury (talk) 15:49, 17 July 2024 (PDT)

I did not realize just how deep this rabbithole went. That is quite a lot of redundancy.
I have opinions on a few of these:
    • {{Sdktools}} — The Third Party SDK Tools has so little distinction between each tool's scope that I don't find it practical to use, with or without colors. It's just too overwhelming. I have already considered two specific ideas for this:
      • Split tools not dedicated to Valve's engines (e.g. Photoshop) into their own navbox called "Industry Tools."
      • Add subsections to clarify the purpose of certain tools, similar to what {{VDC-navbox}} has. (Counterpoint: This may make the navbox even larger.)
    • {{Half-Life games}} — There is a lot of clutter in this navbox, and it's difficult to read much between the lines. I think this should be limited to games that were released and published by Valve (including the Gearbox expansions). An argument could be made to include Black Mesa because there is some active documentation for it on this wiki, but that documentation is mostly disconnected from the other Half-Life games anyway. For similar reasons, I don't think a separate navbox for "third party" Half-Life games would be necessary either, as they are mainly mods with little connection to each other.
    • {{Branch-navbox}} — While showing the timeline of Source engine branches is interesting, I think a navbox is the wrong format for that. I could see this instead just being split into three sections for Orange Box, Left 4 Dead, and Third Party respectively.
    • {{dod games}} — I don't think this is particularly useful on the articles it's present on and could be removed. Like you said, these could just have links in the "See Also."
    • {{Postal games}} — Aside from the header and sections, literally all but one of these links are external links for Wikipedia and ModDB. This is navigating nothing and should be replaced with independent links on the Postal III page.
    • {{Taito games}} — I think this should be removed for the same reason as the DOD navbox.
    • {{Tobgames}} — By default, this navbox splits up each game by their platform, and I don't understand how that's relevant if all of them are readily available on PC. I'm not sure how else these should be split up, although that may be a sign that this is a little redundant to begin with.
    • {{Xash3d games}} — I don't see this being useful to navigate between the 2 articles this navbox is present on. I think this could be removed.
Overall, I agree with taking action on these. I'd consider {{Sdktools}} to be a higher priority due to its visibility and relevance to the wiki, at least in comparison to the game navboxes. --Blixibon (talk) 03:35, 18 July 2024 (PDT)
There is also the issue of navboxes not being collapsible/collapsed by default. In order for them to be collapsible, if I understand it right, the mw-collapsible class needs to be added to the {{navbox}} based.
I tried it once, it messed up its looks because... of something. I opted not to pursue further that time. It's an absolute abyss of nested templates, and not my forte.
There's also the collision of that idea and the navbox templates having those icons on the right, for editing/purging/etc.
Why they're even there, is also topical. The edit button just makes it easier for someone to vandalise them. The purge does the same thing as the page purge, it doesn't purge just the navbox.
The template page icon and template discussion page icon are usable, I guess. But then if you're there you already have access to talk, editing, and see the instructions on purging. So all 4 can be summed up as 1...
So for navbox template in general, I'd minimise the icon presence and have [hide/show] toggle once the collapsibility is figured out. Then the navboxes can be made collapsed by default.
Large navboxes of course would benefit the most from that. Cvoxalury (talk) 06:34, 18 July 2024 (PDT)

"Requests for comment" on Community Portal

Originally, I created the {{Ongoing discussions}} template not only as a way to bring attention to ongoing discussions, but also as a way of "requesting comments" from other editors by making discussion topics visible in prominent areas. I thought that a separate system explicitly for requesting comments would be too complicated and unnecessary for a community as loose as the VDC. I have toyed with the idea of additional, similarly "dynamic" columns in the Community Portal, although I didn't think they were viable for the aforementioned reasons.

However, I've now discovered that there is a way to transclude categories into pages using an extension called CategoryTree, which the VDC already has installed. This means that an inline box could automatically transclude a category rather than being directly maintained by the community. However, a category (or, most likely, a template which adds a category) would need to be manually added to and removed from the discussion in question.

I've been considering either including this as a separate section directly on {{Ongoing discussions}} or having a separate box in its own column on the Community Portal, and I've created two separate mockups illustrating these ideas. These mockups use Category:Alien Swarm NPCs, although the box would presumably display a category like "Requests for comment" in practice.

This is a mockup of a separate "Requests for comment" box:

Requests for comment
Icon-white-chat-filled.png
Discussions where editors have requested comments from other editors.
Use {{rfc}} on a discussion page to make it appear on this list

An edited version of the Community Portal using this box as a third column (and a mockup for an associated template notice) can be found on my sandbox page.

This is a mockup of {{Ongoing discussions}} itself edited to transclude this category:

Considering the fact {{Ongoing discussions}} has already been serving its purpose well so far and is already used on several pages, I'm personally leaning towards integrating this category into it rather than using a separate column.

I do think this may reduce or confuse the reasons to edit {{Ongoing discussions}} directly. If you can now "request comments" through a template notice, then under what circumstances would you directly add a discussion to "Ongoing discussions"? Do you list your discussion there after someone responds to your request for comment?

I'm curious to hear input from others on this idea. Having an entirely new system in addition to the ongoing discussions adds complexity, even if it is a much simpler process, but I also think both of these boxes have tradeoffs which can't be satisfied by the other. Since it's manually formatted, the ongoing discussions box explicitly explains what the topic is, while the requests for comment box only displays each associated page's title and doesn't link to topic sections. However, since the requests for comment box can presumably be maintained through adding and removing a single constant {{rfc}} line to a talk page, it may be a lot simpler and easier to maintain in the long run. --Blixibon (talk) 09:43, 20 July 2024 (PDT)

I think the idea has quite good potential.
• Can that 'marker' template lead to individual topics on discussions, can the code accommodate for it? is there something like a {{FULLPAGENAME}}#{{SECTIONNAME}} for that kind of functionality?
• I'd say {{Ongoing discussions}} panel can be viable as a two-column table with one column for Ongoing discussions, one for Request for comment?
(its top icon can be made smaller to fit on one line with the column title, then, and save 1-2 lines more of space for the lists)
That way it can display a dozen links if there's every that many, without shifting elements down upon expansion.
• I think there'd still be a reason to have both. R.F.C. sounds like something I'd personally use more freely on something I don't feel justified to elevate into O. D., but want input on. And it's a broader definition, sometimes you need a comment as a clarification, O. D. sounds like it should be used for more developed discussions (either already more than a few exchanges or with a clear potential to cause them). And the need for comment may be resolved faster in some ways, an ongoing discussion may take days or weeks, sometimes even more.
Personally, and maybe I'm missing some better way to do it, but I rely pretty much on Recent changes to keep track of both articles and talk pages, and sometimes it just gets taken over by editor/bot activity, understandably we've been having more turbulent time lately than usual. So having a place to pin things to is... kind of should've been there since always, in retrospect.
In the end it depends on the people, getting editors to use it. Having it put behind fewer extra clicks would be quite good, I've asked about putting Community Portal on the sidebar in the Administrators' Noticeboard recently...
Cvoxalury (talk) 14:57, 20 July 2024 (PDT)
In regards to your points:
• Unfortunately, I don't think that kind of functionality exists. Since this is drawing pages directly from a category, it is bound to the limits of a category, which can seemingly only use direct page links. Theoretically, there could be redirects in the category which link to the associated sections, but I don't think that's feasible for this.
• Giving the panel two columns is an interesting idea I hadn't considered. I experimented with this on my sandbox page and I think I'm in support of that.
• This is what I thought as well, although I wasn't sure if others would agree on O.D. continuing to be useful for developed discussions.
I think looking at recent changes is indeed the best way to see all activity right now, for better or for worse. The ongoing discussions board (and, if implemented, requests for comment) is supposed to be a more focused and intuitive alternative to that which highlights discussions and ensures topics don't get left behind. That being said, I still included a link at the bottom of the board to show all recent changes specifically in talk-related namespaces (and VDC namespaces, since that includes pages like this one) to try to make the practice more obvious. --Blixibon (talk) 17:56, 20 July 2024 (PDT)
Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Valve_Developer_Community:Proposals&oldid=438758"