danimesq
commented
5 years ago @joehand
opening a ton of issues, many without descriptions, is not very kind or supportive.
Because you or someone else thinks I'm giving orders or creating duties for you all? Closing tons of issues (asking for a beneficial rebrand of Dat frontend that is Beaker, improvements for Dat's VCS, ask if it runs through mesh networks, reporting tons of bugs that were ignored and suggesting built-in sites) is what is not kind or supportive.
If users aren't supported, an project is not supported.
The majority of projects I know on GitHub, left the issues open even if it is already on the internal roadmap, to make the tracking transparent; when implementing or fixing a bug, they mentions the issue and closes it. And that is the workflow of great projects I see here: they doesn't uses issues as just issues, but as idea and discussion aggregators.
More time will be required to manage and understand your issue now that it may be worth.
I'm scared about how many seconds or minutes you would have to understand this issue by just the title: "Default window frame, with tabs overlapping" Default window frame is the frame used by default on OS windows, and if tabs overlaps it, that's like how is on Firefox, Chrome and other browsers.
As a human, you can intuitively understand simple things that doesn't needs descriptions. Most of the projects I open issues, can clearly understand without wasting time, and on rare cases they asks for elaboration.
A recent example is on ZeroNet: Most of my issues aren't descriptive, but some are, as this I've opened: I've described which plugin it needs and how it could work. After explaining for two times with long texts, the ZeroNet creator funnily couldn't understand: https://github.com/HelloZeroNet/ZeroNet/issues/1835
This adds a lot of mental burden to the maintainers.
Same when they closes issues without reason.
May I suggest getting a better sense of the goals and direction of the project before opening more issues?
I thought the goal of Beaker is to be a browser to disclose about Dat. About understanding the direction of an project, as an casual user I don't dive on technical parts of projects, and I believe on healthy discussions through issues, and they works on 99% projects I support.
And if they are worthwhile and relevant issues, please spend at least some amount of time describing them.
Spend at least some amount of time? I've spend more than 1 hour looking at Beaker and brainstorming to create new issues to improve it, and a whole day today projecting Beaker Quantum concept (https://github.com/beakerbrowser/beaker/issues/1310) as a rebrand to put Beaker together with Vivaldi/Brave and other browsers that are rising, to promote the Dat protocol.
Why would someone spend 30min to an hour understanding and fixing an issue if you haven't even taken the time to describe it?
Are you joking? (I don't know why I'm asking instead of assuming) 30min to an hour is an hyperbole, right? I take the time to describe it when I know it is need; an project's maintainer doesn't haves the risk to be forced to understand and haves possibility to ask for details, but users/supporters can't risk to have issues closed or ignored, like seem on Beaker.
brechtcs
@DaniellMesquita opening a ton of issues, many without descriptions, is not very kind or supportive. More time will be required to manage and understand your issue now that it may be worth. This adds a lot of mental burden to the maintainers. May I suggest getting a better sense of the goals and direction of the project before opening more issues?
And if they are worthwhile and relevant issues, please spend at least some amount of time describing them. Why would someone spend 30min to an hour understanding and fixing an issue if you haven't even taken the time to describe it?