Solved Can we force users to add a version tag to questions in Spigot Plugin Development?

Discussion in 'Community Feedback and Suggestions' started by stonar96, Jan 7, 2020.

  1. Sometimes there are questions in Spigot Plugin Development where my answer strongly depends on the server or API version, which the OP uses, but there are hardly any questions where a version info is added. That's probably because most users don't even consider this as an important info.

    My suggestion is to add a kind of a tag or a text field, which can (or must) be filled in by the creator of such a thread. I think that this makes the process of answering questions much more efficient in many cases. I appreciate any feedback on this suggestion and would be very happy if it was added.
     
    • Agree Agree x 10
  2. I agree - think this would help
     
  3. Most posts made by new users to get help lack a lot of essential information, this would help and avoid wasting time asking for the version.
     
    • Like Like x 1
  4. I'm going to go against the grain here and say that I think this is a strange knee-jerk reaction to a very minor issue. It sounds like no thought has gone into anything but the sunshine scenario.

    People tend to focus primarily on all the good things that a given feature can give way to, and rarely on any of the bad things it can give way to. If you think there are no downsides to your idea, then you haven't given it enough thought. Some specific points:
    • If this field is mandatory, then people may be deterred from asking their questions if they are not version specific (sometimes the questions are of a less Spigot-centric nature and more general, and the rules do not forbid such questions). It's an unnecessary filter.
    • A mandatory field gives you no guarantee of correctness nor precision. People can type whatever in there. Is the patch portion of the version string relevant or not? Is the build number relevant? Maybe this is about a bug that was fixed in a more recent build? People are much more likely to provide sound info when asked specifically about it than if it's just part of a form (think about all the times you've had to fill out a form for something and had to provide a bunch of completely irrelevant information). It's an obstacle whose value is conditional at best and questionable in the general case. It creates unnecessary friction.
    • An optimal field won't be used in the cases where it is the most relevant. People who are unaware of discrepancies between versions won't bother to fill out an optional field. People who are aware will likely already be on the right track. It's likely to be filled out when it is the least relevant.
    This is a forum, not an IT HelpDesk ticket system. There should be no need for "efficiency" and low turnaround times. If you feel like you're "wasting time" asking for version strings, then perhaps stop doing that and start doing things that you enjoy instead.

    God forbid we have actual, organic conversations on a social platform...
     
    • Agree Agree x 5
    • Creative Creative x 1
  5. No one said it would be mandatory!
    Yes, it is open to human error! (It is a Human User Interface.)
    Who said it should be a 'text' field? (It was suggested as an option.)
    God has nothing to do with anything here and is certainly not organic!
    Such a negative reply as yours could insinuate that this may be an ant-social platform!
    Did you even consider weighing up the positives?

    I think that I raised this topic a while ago and just got Poo-Pooed by those who don't like change!

    What is wrong with having a Drop-Down with basic version numbers to guide the topic?
    A default option can include 'No version chosen' which would not add a 'version tag' to the post's header.

    Or even, simply point the post creater to a 'Good Posting Guide' before they can proceed to create their post?

    I just get the impression that any suggestion which may improve the forum will be rejected if it it unnecessary?
     
    • Like Like x 2
    • Agree Agree x 1
    • Funny Funny x 1
  6. TheJavaHacker

    Supporter

    From the OP:
    Also I would like to weigh in -- This is a decent suggestion on the grounds that it may speed up giving support to a user (if we don't want to support older versions, filter by version tag); however it can potentially cause a lot of problems for the end users. Say, they don't know how Xenforo's tagging system works, then how would they know how to use it? Or for example, their issue falls into multiple versions, but we only have the specific version tags - How would we know to assist for multiple versions?

    Again, decent suggestion, however improvements may be required.
     
    • Agree Agree x 1
  7. First of all, thanks for the detailed feedback. I will not disagree with your points, but I want to clarify some things here. What I have suggested is just a non-final concept of an idea. I don't ask for a very specific implementation of the suggested feature. If you give it even more thought, you will notice that most of your concerns can be easily fixed by adjusting the implementation. For example there could be a "default tag" which says "version independent". I have also said that it may or may not be mandatory. Instead of focusing primarily on all the bad things you can also think about how to improve or fix the bad things.

    Also note that I like posting on this forum very much. Please don't get the impression that I think I am "wasting time" here, but that doesn't exclude that I am trying to suggest something to try to improve the thing I like and what I spend much time with.

    (Note that arguing such things in english is sometimes difficult for me.)
     
    #7 stonar96, Jan 8, 2020
    Last edited: Jan 8, 2020
  8. Make it a required field and only allow tags from 1.13.x - latest and the rest get the unsupported tag.
     
    • Agree Agree x 1
  9. Uh. But people still make things in those lower versions. :oops:
     
    • Optimistic Optimistic x 1
  10. The Op said
    That is an option of two choices!
    I also included
     
  11. MiniDigger

    Supporter

    I just assume they used latest and if not I yell at them :p
     
    • Agree x 2
    • Winner x 2
    • Like x 1
    • Funny x 1
    • Optimistic x 1
  12. We're developer, if there's anyone who's not against change it'd be people like us. There is a difference between a useful change and a useless one. You can't just look at an idea for 3 seconds and deem it worthy to be added without considering the rest of the users, the purpose of the platform or how viable it even is.

    In this case, I agree with @garbagemule as I don't think this will be of any use. In fact, I think it'll do the exact opposite of being useful. This is a forums, not a ticket / support platform. If people have a question about your plugin, write documentation beforehand. If that doesn't answer their stuff, just answer the question and ask for a version tag if they didn't provide one. There's then also the problem how every developer probably sets their own fields they'd want to have. You just don't want to have this in a forums software, really. If they found a bug, they can also just report it on a Github page even if your source code is private, you can have a separate (public) repo just for storing ticketst. There, you can specify formats and use bots that automatically categorise tickets by specific tags or post replies if certain info or a format is missing.

    Edit: misread some, thought this was about plugin usage, not development. TL;DR new point; Spigot supports the latest, no point in adding tags for older, probably unsupported versions.
     
    #12 MrDienns, Jan 8, 2020
    Last edited: Jan 8, 2020
    • Like Like x 1
  13. I'm personally against putting an 'Unsupported' option in the list. 'Unsupported' sounds, at least to me, as "no one will answer your question". If you want to ask a question for an older version, would you put this tag on it? I don't think people would do that, at which point they'll either leave it blank (if it's optional) or specify a version that is 'supported', which defeats the purpose, because now you don't only not know the version, you are thinking they use a version that they aren't actually using.

    I like this idea (as an optional tag), but instead of adding 'Unsupported', adding the versions from, say, 1.7-1.15 as a list from which the user chooses from (I don't think there's actually anyone who is developing for 1.6 or lower). And if the user uses an outdated version and you don't want to help them with that, you can easily just ignore the question altogether.
     
    • Useful Useful x 1
  14. But it simply that, everything below flattening should not be supported.
     
  15. What are you talking about? This isn't about someone's plugins, I am talking about the Spigot Plugin Development forums. Can you please explain a bit more in detail why you think this would be the opposite of useful? If you are against it, please provide information what exactly is wrong with it, so we can possibly improve the idea.

    What does this have to do with it? That's not a reason why it would be the opposite of useful.
     
    #15 stonar96, Jan 8, 2020
    Last edited: Jan 8, 2020
  16. The thread title literally uses the word "force". Besides, I made three points, two of which assume that the field is mandatory, one which assumes it is optional. Please re-read my post.

    The goal of my post was to provide perspective, not to give a balanced view of the whole thing. I specifically said I was going to go against the grain.

    The problem with the suggestion as a whole is a lack of attention to drawbacks. There are no silver bullets. By ignoring the potential downsides, you are not painting the full picture, and that is a problem. By focusing only on "your side of the coin", you're setting the other side up for frustration.

    Who does this change suggestion benefit? It's not the person asking the question. It's the person answering it. This makes it an obstacle for the person asking the question. An obstacle that is only sometimes relevant to overcome. It's unnecessary clutter. And again, this is a forum. It's not a ticket system. It makes sense to put up these types of gatekeeper mechanics in a ticket system. Not in a forum.

    If you truly believe that this is overall an improvement, it is your job to make an informed and fair rundown of the pros and cons. If you can't take the cons seriously, or if you aren't even mentioning them, the amount of negative impact remains undefined. There is always negative impact. If you don't know what it is, the positive impact doesn't matter. The risk is effectively infinitely big while the benefit is finite.

    You don't know if this will improve anything. You think it will make things easier for you. That's fine. Who else is impacted by it, and does it also benefit them?

    ---

    This is simply not true. A barrier of entry is a barrier regardless of how pretty it is. You are still placing a burden on the person who is asking a question without knowing if that burden makes sense to carry.

    I think you're missing the point. The data quality of the values in this suggested field is never going to be high enough to be useful in the general case. If the field is mandatory, people will put junk in it. If it is optional, people won't fill it when it's relevant. Those are your options and outcomes. This is the reality you have to address. And yes, that makes it difficult to vouch for!

    That specific comment was to the guy mentioning time waste.

    But it still applies to you. The change you're suggesting benefits you, not the person you are trying to help. This means that you have to create incentive in some way, and you haven't talked about that. You are not addressing the duality of the situation, only your own side.

    To be sure, try to search around for information on why bug reporting is hard and the struggles that come with being "tech support". And then read up on the UX issues surrounding "forms". And then finally, draw a parallel to the purpose of an internet forum and decide for yourself how similar these concepts are, objectively.

    The root of the problem you have has been solved, by the way. The solution is StackOverflow.
     
  17. My bad, was assuming this was more towards plugin usage, not development. Even so, Spigot supports the latest, I doubt tags will be added to support older fields. You shouldn't be using an unsupported, old API anyway. Even if they do, people should just state the version. I don't see it being worth to add tags just because some people forget to mention their version. Just ask and get a response, simple.
     
    #17 MrDienns, Jan 8, 2020
    Last edited: Jan 8, 2020
    • Like Like x 1
  18. You are claiming that it will provide a value, but you have not made any attempt at outlining the cost, nor the magnitude of either. Simply put, you are ignoring the cons and you are putting the pros on a pedestal. That's not very constructive.

    What this place "is" is actually very relevant to the suggestion you're making. You need to consider the purpose of this place and its format. Your suggestion would disrupt the format, pulling it closer to that of a ticket system. The reasoning behind your suggestion is the exact same as the one used to set up the required and optional fields in a ticket system. "We must know what operating system you're running", "we must know which browser you're running", "we would like to know which version of your browser you're running". No one denies the potential usefulness of these pieces of information, but denying that they are situational is just ignorant. It's fine in a ticket system, because you want to filter out the low quality bug reports so the dev team can stay focused and not run around like headless chickens.

    This is a forum. It's a place where people can talk about things. It's casual, laid-back, and it has a low barrier of entry. That's how forums work, it's how they are designed. In this case, the chat is about plugin development. It is not limited to "my code doesn't work" posts, and the replies are not limited to "fix it by doing this, case closed, fuck off". If I want to talk about something like software architecture in my plugin, this would be the place in which to talk about it. But in that case, the version string is utterly irrelevant. It's just clutter.

    ---

    So let me flip this one around with a slippery slope argument and ask you "to what end?". If we decide to include a version string field, I suggest adding all of the following fields as well, since they are also situationally useful:
    • Build number
      (because sometimes the server version is not fine enough granularity)
    • Classes and interfaces in the Bukkit API that I have used (multi-select dropdown):
      - org.bukkit.Bukkit
      - org.bukkit.Color

      ...
      (useful because knowing what people have experience with tells us whether or not they know about just the right classes to use for their specific problem)
    • Years of experience with software development
      (useful because no experience means having to explain concepts more clearly, whereas lots of experience means we can assume certain concepts are understood)
    • Years of experience with Java in general
      (useful because helping people new to Java but with software development experience is different to helping people new to Java and software development in general)
    • Years of experience with the Bukkit API
      (useful because people who are just starting out probably don't know about some of the more advanced functionality)
    • Years of experience with NMS
      (because if the solution requires NMS, we'll know whether or not we can just say "use hacky packet no. 29" or if we have to explain that this is a world of pain and no one should ever go here)
    • Educational background
      (because computer science majors will understand certain terminology and algorithmic concepts that hobbyists may need to have explained more in-depth)
    • Preferred editor
      (useful because people like bashing on Eclipse, so then they don't have to ask before making snide remarks about it)
    Reductio ad absurdum. Your goal now is to argue why these fields shouldn't be included, but yours should. Why are they different?

    ---

    Logical fallacies aside, hopefully this helps shine some light on what some of the problems with this suggestion is.

    With Java 8, we got default implementations of interface methods. But Java doesn't allow us to override the methods on the Object class (e.g. equals and toString). Brian Goetz made a comment about how people can conjure up a lot of ways that some functionality can help them write better code, but often fail to see how it can also "help" them write worse code. Is it worth allowing the few who know what they're doing to write better code if it's going to mean that a lot of other people will end up writing worse code? The same kind of perspective applies here. Maybe it will be helpful to someone, but it will likely get in the way of someone else, or it will create unnecessary clutter. Is it really worth it with all of that in mind?
     
  19.  
  20. When I started using Spigot I used to download the jar from some website and most of the time it was not the latest. I don't know if new users do this, I did it because I didn't want to use BuildTools.
    It would have been great if someone yelled at me for doing it but after some time I figured out how to use buildtools.
     
    • Like Like x 2