Why is github issues long left to be answered

Some major bugs are reported on github issues but they are long left to be answered.
For example, this one

The problem really bothers me a lot

It's not clear from that GitHub issue if there is a bug in Joplin or if this is user error. Joplin does not have a team that's paid to groom the issue log. This means that issues that aren't obviously a bug, and aren't easily reproducible won't be fixed.

If you want it to be fixed you'll need to provide a reproducible test case. It would be enough to list step by step instructions that trigger the bug.

This is the blessing and curse of open development projects like Joplin. Users have the power to fix bugs and add features themselves. But they also have the responsibility to provide detailed error reports.

I know that it's not fair to expect every use to know how to make a nice bug report, but it's also not fair to expect someone else to volunteer their time confirming bug reports (especially when that time could be spent on fixing bugs with valid reports...)

7 Likes

Github issues are only labeled if they are confirmed bugs and only those are worked on.

Must confess I do not use the WebClipper often, but can not recreate this behavior in my tests.

Therefore, it is best to write a step by step guide on how to reproduce the behavior.

1 Like

The issue is not submitted by me but I came across a similar problem the other day. Joplin on Windows. This is my way to reproduce.

  1. Open the PC version and add a picture to any note. Sync after that.
    (Joplin on Windows uses absolute paths for pictures.)
  2. Then sync on Android.
  3. Pictures added on PC can't be displayed normally on Android.

I found a way to change the absolute path to comparative path manually. I m wondering if it is possible to avoid using absolute paths for images on PC.

With your description I can't replicate the problem.
Write an exact step by step description of how you added the images, as there are X ways to add images. Also include which editor you are useing.

okay i ll post a more detailed way to replicate the problem.
1.open any note
2. add an image by clicking on the 'insert image' button or drag&drop (under the default text editor)
3. the image can't be synced to android.
4. Then switch to markdown editor I found out that all the image is in absolute path.

thanks for your hint. I found out that if i m under markdown editor, joplin wont use a absolute path instead of comparative path to add a image and the image can be synced successfully. So is it a feature?

I can't replicate with those steps (although there is no 'insert image' button, I assume you mean the 'attach file' button)
Using Joplin 2.8.8 on Win10 it always returns an internal Joplin resource id, not a local path no matter which editor I use. Same behaviour if I drag & drop or use 'attach file'.

yes i mean the attach file button sorry
图片
that's wierd

Weird, Joplin obviously tried to integrate the file rather than just linking to its original location as it is stored in .../joplin-desktop/resources, I simply can't get Joplin to behave in that way no matter what I try. Interesting that it creates that query string thing after the .png, I wonder if that is a clue.

well thanks anyway

I can reproduce following the instructions/clues from the GitHub issue.

  1. Create a new note and attach an image to it.
  2. Copy the image with Ctrl+C using the WYSIWYG mode.
  3. Create yet another note and paste the image with Ctrl+V using the Markdown mode.
3 Likes

I have the same issue with copying an image from a note and pasting on another with the rich mark down.This causes those images to be broken on Linux client app

1 Like