4

Recent question: Suspected-bug Tag motivated me to elaborate on an idea I had in mind for some time now. It appeared to be not close enough for linked topic so I'm posting it as a separate one:

Currently we have and sometimes we use +. Additionally with the header we can get information about the bug status.

It is too limited in my opinion because:

  • I'd like to review the state of unfixed bugs when a new MMA version is released. It is tough to filter out 'fixed' bugs as this keyword can appear anywhere in a body e.g. "why isn't it fixed since 2010?!"

  • I would like to skip bugs related to 3rd party packages, on the other hand they deserve the and Paclet version information

Additionally:

  • adding and other new tags will pollute the system and occupy 2 out of 5 tag spots.

  • Documentation bugs using two tags is justified but at the end it should also be solved with whatever solution we choose.

  • if we commit to special tokens we need them to cope with search engine well. easily searchable and not interfere with similar words.

I think there should be only one tag: and I'm going to suggest what can be done in separate answers to get feedback from community.

6 Answers 6

Reset to default
8

Admittedly this isn't clean but insofar as the standard header as been followed it should be possible to filter as desired, with acceptable accuracy, using

[bugs] is:question -"and fixed in" or its antonym [bugs] is:question "and fixed in"

3
  • Ok, I agree this makes FixedBug superfluous. What is your attitude towards the idea in general. p.s. is:q works too.
    – Kuba
    Commented Mar 22, 2018 at 8:58
  • Do you know how to make -"11.3" work? The idea is to use [bugs] is:q -"and is fixed" -"11.3" to select only those which are pending review.
    – Kuba
    Commented Mar 22, 2018 at 9:50
  • 2
    @Kuba No, I don't know. You might try asking on the main meta site. Sorry. On the broader subject I'm not sure; I am not active enough at this time to feel fully immersed in present usability. The site isn't specifically set up for this kind of detailed bugtracking and filtering, so any solution probably feels a bit "shoehorned." The existing header feels acceptably human, and I have some reservation about making it too mechanical (not that your proposals would.) Incidentally I cannot recall if it is possible to search for embedded metadata within posts themselves; can you?
    – Mr.Wizard
    Commented Mar 23, 2018 at 21:43
5

We should not change anything about how we handle .

4
  • Personally I do not find the other alternatives convincing. After all, if Mathematica's pattern matching cannot help to detect "fixed" (or "resolved") in the bug header - we may have other problems than bugs...
    – gwr
    Commented Mar 16, 2018 at 16:06
  • Also: Assume, that there is reasonable confirmation among the community for bugs - that should completely suffice. Since a bug pertain to a certain instance of the software it cannot be fixed for that instance and thus should be kept clearly visible for all users of that version. A well maintained (!) bug header will then contain all relevant information. Maybe there should be a clear guidance for an additional head for [Case#] right below the bug header?
    – gwr
    Commented Mar 16, 2018 at 16:15
  • @gwr I'm talking about StackExchange search engine. You can't use search for all bugs which are not fixed for example.
    – Kuba
    Commented Mar 16, 2018 at 18:35
  • 4
    @gwr Mathematica's pattern matching certainly can handle it (as can any language with basic regex support) but that requires downloading all body text for anything labeled bugs which is expensive and requires consistent maintenance of the database.
    – b3m2a1
    Commented Mar 17, 2018 at 21:43
4

FixedBug token +

FixedBug introduced in X.X and fixed in X.X.X

This prefix fo Bug will be useful because 'fixed' keyword may happen somewhere in the body and the search will be corrupted for cases where the bug is not fixed.

1
  • 5
    From a developer prespective this would be useful. It takes too much time to figure out if a certain issue still needs attention or if it has been fixed already. Perhaps it could be called BugFixed then it would be an autocompete cousin of bugs (which really should be called Bug - singular.)
    – user21
    Commented Mar 16, 2018 at 13:21
2

PackageBug token +

PackageBug (+package version spec)

Bugs in 3rd party packages

7
  • How many do you think are there of those?
    – user21
    Commented Mar 16, 2018 at 13:17
  • @user21 I hope there will be a lot in future. And if there aren't any it does not harm to keep this convention in mind for future.
    – Kuba
    Commented Mar 16, 2018 at 13:21
  • A lot of 3rd party packages :P
    – Kuba
    Commented Mar 16, 2018 at 13:21
  • 2
    Fair enough; if you change your mind about the need of bugs, let me know it's not a problem delivering them.... ;-)
    – user21
    Commented Mar 16, 2018 at 13:22
  • But what sense does it make, to assign two tags then: If the package is not working then why assign bugs (redundant information)?
    – gwr
    Commented Mar 16, 2018 at 16:04
  • 2
    @gwe Token is not a tag but a part of header. Not everyone has the newest release so what is fixed for you does not need to be for others.
    – Kuba
    Commented Mar 16, 2018 at 16:31
  • 4
    @user21 I have hundreds (or more) of bugs spread across my packages :) As more people use my stuff they start to surface and so this would be useful for me.
    – b3m2a1
    Commented Mar 17, 2018 at 21:46
1

DocumentationBug token +

DocumentationBug (+mma version spec)

For serious flaws in docs, we are already using + we should add this token to have a uniform system

2
  • What is this supposed to indicate: a) Documentation does not describe the behavior of Mma correctly (documentation has an error), or b) Documentation seems correct, but Mma does not behave as it should (Mma probably has a bug), or c) neither documentation nor Mma seem correct (e.g. error + bug)?
    – gwr
    Commented Mar 16, 2018 at 15:57
  • 1
    @gwr Wrong/very misleading/self inconsistent documentation.
    – Kuba
    Commented Mar 16, 2018 at 19:36
0

SuspectedBug token

SuspectedBug

For unclear cases, pending confirmation etc. This question must not have .

1
  • 3
    Whose confirmation is pending here? So far, bugs is only assigned if community (=sometimes as little as one person giving approval by comment and then assigning tag) has confirmed. Therefore this looks redundant. Or is it meant as WRI-case to be opened?
    – gwr
    Commented Mar 16, 2018 at 16:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .