If little bugs aren't fixed in Atom, does this editor have a future?

#1

I’ve been using Atom as my primary editor for a few months, and I enjoy using it for the most part. Before that I used VS Code for almost a year.

I decided to go back to Atom because I want to support a truly open source editor (as far as I know, it’s open source through and through). Also, I have a more powerful laptop so I don’t notice the additional demands on resources, compared to VS Code.

I noticed a silly bug where the cursor doesn’t move to the correct position when inserting a comment using CMD + /. I opened an issue on GitHub (#17199) after noticing that a previous, similar, issue (#4784) was marked as stale in September 2017, and closed.

My issue was closed because it was marked as a duplicate of #4784 and I was given the following feedback:

Because we treat our issues list as the Atom team’s backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn’t an exact duplicate but is closely related.

This feedback, in itself, is good feedback. It explains why duplicate issues are closed. It’s a reasonable approach to take.

My concern is more that the “original” issue went stale in September 2017 after being reported in December 2014. This issue just isn’t being dealt with, and it looks like it won’t be dealt with.

Granted, this bug isn’t exactly mission critical, and I manage to do what I need to do with it manifesting. At the same time, it leaves me wondering if ignoring these little bugs bodes ill for Atom going forward?

If I had the knowledge, I’d be happy to work in this and fix the issue. I wouldn’t even know where to begin to address it so I’m reliant on the developers who do work on these issues.

While Atom is improving, for sure, not addressing these smaller issues is worrying. For one thing, it’s a fix that could save a noticeable amount of time and keystrokes. It also reminds me of the policing policy that was implemented in New York at one point. I think it was called “Broken Windows”, or something like that.

The idea is that the police wouldn’t even tolerate small issues. They’d address everything and, in the process, improved policing across the board. I’m not familiar with what it takes to maintain something like Atom but it seems to me that adopting a similar approach would improve Atom overall.

#2

Hello.

Complaining about something that you get for free…? :thinking:

I cannot fault you on your logic. I was thinking along similar lines when looking at how many old issues are still open.

Some rhetorical questions -
Are you doing something to pay-it-forward? A something that eases the work of the developers; free some of their time so they may spend time on these issues. It may even be a something unrelated to writing code.

Or perhaps: Are you willing to sponsor a free-lance coder to work on some issues? “Payment” does not have to be money; it could be teaching someone about something you are well versed in. You have something worth trading - everyone does.

just my 2c 25c1




1 - inflation

#3

Hi @danPadric

Firstly, this is a good point. I hadn’t thought about contributing to projects like this quite this way before:

In my case, my contributions are usually reporting issues with as much information as I can. It may not be much but that’s something I can do.

Secondly, I didn’t post the message to complain. Sure, I find it frustrating and there is a little bit of a complaint in there, but my motivation for my message was to raise a concern about this issue.

Perhaps I have an expectation that these sorts of issues would be addressed because the developers who build this terrific app have set a high standard when it comes to functionality, and features. That expectation may be unfounded, and perhaps the appropriate expectation is that Atom is what it is.

I’m certainly grateful to have such a feature-rich, and capable app, that I rely on daily. If the answer to my message is that issues like the one I highlighted will be resolved if, and when someone has the capacity to deal with it (possibly not at all), then fair enough.

In that case, I adjust my expectations accordingly.

#4

Hello.

Thank you for a positive feedback.
Perhaps some reality check is in order.

As someone on the sidelines, my opinion is that Team Atom is effective and productive. Keep in mind how “small” the team is and how much get done.

This implies that the issues have priority rated according to the attributes:
(written from opinionated experience - not complete list)

  1. Grade of influence to the global program function.
  2. Grade of influence to the community.
  3. Possibility to change the way user interacts with the software as workaround.
  4. Grade of description describing the issue clearly.
  5. Ability to reproduce the issue.
  6. Indication what causes the problem. Bonus points if know which code segment to adjust.
  7. Time spent on issue vs benefit for solving it.
  8. Grade of influence to other working functionality.
  9. Planned Future advancement would automatically fix the issue.
  10. How well the code needing change is understood and documented.
  11. Grade of interest (motivation) from the coder to fix the issue.
  12. Grade of insistence from the community to have the code changed.
  13. Incentive to work on the issue.
  14. Time involved to test a possible solution.

Whichever of these points can be influenced with a issue description can push the case to a higher priority.

Not all issues are “broken windows”. Some are very irritating squeaking doors.

Have a good Sunday.

#5

A legitimate question is asked, and the initial response is “Complainer!” Followed by a list of “How things here are done”.

None of this addresses the OP. And it is a concern. My initial response to the question is, “No, I don’t think it does.”

That’s a hard pill to swallow, and no one specifically is to blame, but it’s the truth for some. Bug that are allowed to go stale is a really concerning issue, because it over time it makes the editor feel “rough around the edges”. It’s for that reason I stopped using it a while back, but I keep checking in now and then, hoping that things have changed, or that more organization in development has manifested.

Yes, it’s just two people in this thread who have voiced their concerns thus far, but you know we’re not the only ones. Something like this has a tendency to trend.

There’s no indication that Microsoft is getting involved in Atom’s development, but maybe that would be a good thing?

#6

Yes, it’s just two people in this thread who have voiced their concerns thus far, but you know we’re not the only ones.

I noticed a lack of reactions in those two issues. To me these reactions often signal the importance of an issue. So, anybody who has the same problem but doesn’t want to get involved in the discussion should at least click on :+1:

However, it feels that the Atom developers are especially ignorant on reported issues. I wonder why that is or whether it has to do with the fact that a lot of functionality is split into seperate packages (=repositories).

#7

This is a factor, for sure. At the same time, I had to remind myself that it’s not like there are infinite resources to fix every issue that everyone raises. If Atom falls behind in ways that are important to users, they’ll move to alternatives.

Before I returned to Atom, I used VS Code religiously. This was mainly because my previous laptop couldn’t run Atom particularly well, and VS Code is much lighter on resources (leaving aside some of the amazing functionality in there).

I returned to Atom because I really want to use an editor that seems more open to me. I also have a long-standing distrust of Microsoft from the Bad Old Days. Whether that’s still well-founded, I’m not so sure.

#8

Hello.

How about some positive community action?

Would you be willing to administrate a community driven list of functionality that is not working as intended?

The administration is not just the creation of the discuss.atom.io topic. In my view such topic will be taken seriously and start to carry weight if:

MUST

  • split the list into categories
    • core
    • auxiliaries
    • core language
  • list is prioritised by importance … to your good judgement
  • a item links to a well described reported “bug”
  • community can “like” a suggestion when agreeing on the sentiment
  • it should not be a new feature
  • it should not be something such as “in THAT editor it works like THIS”

GOOD TO HAVE

  • maximum time to spend on the item estimated
  • rating to how many users are effected
    • all
    • many
    • some
    • me

BONUS POINTS
(advance to high priority)

  • link to code where the problem originates from
  • link to a workaround or coded solution
  • any research that may help finding a solution
  • core functions

In my view:
For each list item contribution (“bug”) someone makes he also needs to mention an equal number of unique (not mentioned before) positive usability attributes of Atom. The person who can not find balance in good and bad about Atom, should best be using another text editor.

Carefully study the iteration plan which the Atom Team is working on. Consider from this insight where to recommend where community listed items should start break into:

  • first
  • middle
  • last

No promises or guarantees but…
If there is enough world-wide interest in making such a list in a co-operative way. How can such efforts be blankly ignored.

BR

#9

Would you be willing to administrate a community driven list of functionality that is not working as intended?

I’m certainly happy to contribute when I come across issues, but what you describe is a full-time job in itself. Besides, isn’t that what GitHub Issues amount to?

#10

Yes and Yes.

Was it not the purpose of this conversation to influence the way the project is executed when reporting issues on Github-system failed to deliver the result hoped for?

#11

@pauljacobson My approach has always been to try and find a quick workaround after reporting an issue. In your case, insert the following in your snippets file:

'.source.css':
  'css-comment':
    'prefix': '/*'
    'body': '/* $1 */'

Now open a css file, type /* and hit TAB. You’ve just inserted a comment and your cursor is positioned inside. Granted, this isn’t perfect and isn’t consistent with Cmd-/, but at least it’ll do what you want until the bug is fixed.

#12

Hi @dpo, I only just saw your suggestion now. Thank you!