I think it would help to open an issue on github making explicit the following three points explicit in the report:
- steps to reproduce from scratch;
- what you expected to happen;
- what you actually observed (include the screenshot or video capture in addition to a textual description).
Otherwise, you might risk your report being ignored due to a silent misunderstanding about the mismatch between your expectations and the actual results.
At the time i wasn't sure if it was PEBCAK, which is why i started a discussion in the forums. As there were no replies, i received no notifications, and so I forgot all about it.
Personally, I do not understand why you think there is a bug from this screen capture alone. Maybe because I am that familiar with penpot and figma, but still, I do not find it obvious.
This is why it's important to describe explicitly the three points in text:
- steps to reproduce;
- what you expected to happen;
- what actual result you observe instead.
Something that might be obvious to you but isn't for others will just be silently ignored most of the time.
EDIT: I now see the problem after reading your other reply above:
This is why it's important to describe explicitly the difference between what you expected and what you observed. I swear I did not see the change in button width before reading the linked comment.
I hate how every time someone even talks about an issue with an open source project, some smart alec replies "well did you raise an issue?" - or worse - "did you send a PR to fix it?".
We are all very aware how bug reporting works. And user criticism of bugs isn't somehow invalidated just because the users didn't go to the sometimes very large effort to report bugs.
I wouldn't have reported this bug either. If the example documents are getting corrupted just by navigating them that indicates that it's just a really buggy project (corroborated by other comments here) that I'm not even going to use, so why would I spend my time working on it?
I opened an issue based on the discussion here and it didn't take much time or effort.
(It was one of those form-based issue templates that requires you to explicitly list out Steps to Reproduce, Expected behavior, Actual behavior, OS version, etc. which IMO causes slightly more friction for anyone who knows how to put together a good bug report, but I've also seen enough poorly-specified issues to know that it's necessary sometimes)
I can see both sides of the dilemma and I don't necessarily like when a maintainer defaults to "open a PR" but asking for a reproducible issue wherever requested is not too much to ask.
With a PR I understand not wanting to put the effort in as it may not be merged. But offering up a reproducible example on the correct forum is the least you could do. If you want the problem fixed that's the best way forward.
I think it would help to open an issue on github making explicit the following three points explicit in the report:
- steps to reproduce from scratch;
- what you expected to happen;
- what you actually observed (include the screenshot or video capture in addition to a textual description).
Otherwise, you might risk your report being ignored due to a silent misunderstanding about the mismatch between your expectations and the actual results.
At the time i wasn't sure if it was PEBCAK, which is why i started a discussion in the forums. As there were no replies, i received no notifications, and so I forgot all about it.
If anyone is interested in opening a bug report you can see the issue here: https://imgur.com/a/hZ1ja9o
Personally, I do not understand why you think there is a bug from this screen capture alone. Maybe because I am that familiar with penpot and figma, but still, I do not find it obvious.
This is why it's important to describe explicitly the three points in text:
- steps to reproduce;
- what you expected to happen;
- what actual result you observe instead.
Something that might be obvious to you but isn't for others will just be silently ignored most of the time.
EDIT: I now see the problem after reading your other reply above:
https://news.ycombinator.com/item?id=46064757#46069546
This is why it's important to describe explicitly the difference between what you expected and what you observed. I swear I did not see the change in button width before reading the linked comment.
7 replies →
"Content not available in your region"
So, given that Penpot appears to mostly be developed in the EU, you'd need to fix that part first.
3 replies →
I hate how every time someone even talks about an issue with an open source project, some smart alec replies "well did you raise an issue?" - or worse - "did you send a PR to fix it?".
We are all very aware how bug reporting works. And user criticism of bugs isn't somehow invalidated just because the users didn't go to the sometimes very large effort to report bugs.
I wouldn't have reported this bug either. If the example documents are getting corrupted just by navigating them that indicates that it's just a really buggy project (corroborated by other comments here) that I'm not even going to use, so why would I spend my time working on it?
I opened an issue based on the discussion here and it didn't take much time or effort.
(It was one of those form-based issue templates that requires you to explicitly list out Steps to Reproduce, Expected behavior, Actual behavior, OS version, etc. which IMO causes slightly more friction for anyone who knows how to put together a good bug report, but I've also seen enough poorly-specified issues to know that it's necessary sometimes)
"And user criticism of bugs isn't somehow invalidated just because the users didn't go to the sometimes very large effort to report bugs."
Yes, it is.
1 reply →
I can see both sides of the dilemma and I don't necessarily like when a maintainer defaults to "open a PR" but asking for a reproducible issue wherever requested is not too much to ask.
With a PR I understand not wanting to put the effort in as it may not be merged. But offering up a reproducible example on the correct forum is the least you could do. If you want the problem fixed that's the best way forward.
3 replies →