Support Forum
#supportforum Any doubts or questions on how to use Decidim? Check them with the Community!
Dear Decidim,
While I appreciate your efforts to eat your own dogfood, I I find in horribly devastating for the community that you have decided to disable posting new GitHub issues.
As an example, I'd like to ask you to try to format a Decidim proposal similar to this issue at GitHub:
https://github.com/decidim/decidim/issues/4660
This types of issues that provide technical information and possibly ways to solve the issue will be lost in the wind because of the decision to disable GitHub issues. For developers, I believe my GitHub issue provides much more information for finding a solution and reaching a conclusion than those few lines I am limited with a Decidim proposal.
Thank you for your attention.
(While posting this proposal, my initial title was too short and my body exceeded 1000 characters.)
...CONTINUED IN THE COMMENTS...
Report inappropriate content
Is this content inappropriate?
30 comments
While Decidim is a great software (for what it is meant for), it is not a software that has been designed to report technical issues and collaboratively work against fixing those. To me, fixing a technical bug should not introduce a democratic process overhead, it makes it way harder for everyone involved. There is also a much higher barrier for me to log in to Metadecidim and browse through those ~10 steps of navigation that I'm required to do to post a bug report (+ to fix all the unnecessary errors reported by the mandatory etiquette validator). On the other hand, in GitHub, I can just click Issues => New.
Another benefit of using GitHub is that it autosaves what I've written already to the issue. Therefore, if I get caught up with something else (leaving the issue in another tab), I can just return to GitHub, go back to Decidim issues and my issue is automatically there, even if I turned off my computer in-between. In Decidim, I would be required to save my proposal for this.
Conversation with Antti Hukkanen
For me, disabling adding GitHub issues will drastically lower the amount of issues I will be posting. If it makes you feel better, at least at your end it will look like you have less bugs in the software. :)
The correct tool should be used for what they are meant for. You wouldn't hammer a nail using a screwdriver, would you?
There is no intention to pretend that the software has fewer mistakes than it actually has: not at all!
The idea is to manage everything without dying in the attempt, with the resources we actually have.
mistakes = bugs
Hi @ahu
First of all, thanks for your feedback, as always it's spot on.
> For developers, I believe my GitHub issue provides much more information for finding a solution and reaching a conclusion than those few lines I am limited with a Decidim proposal.
So, maybe one problem is that we shouldn't have such a low limit on a Decidim proposal, right?
> While Decidim is a great software (for what it is meant for), it is not a software that has been designed to report technical issues and collaboratively work against fixing those.
We follow the example set by https://meta.discourse.org/c/bug
Decidim should be able to handle debates / ideas exchange.
Once a bug is detected/accepted/financed we'll move the discussion to GitHub.
Conversation with Andrés
> As an example, I'd like to ask you to try to format a Decidim proposal similar to this issue at GitHub:
> https://github.com/decidim/decidim/issues/4660
Maybe we need something like https://meta.discourse.org/t/migrate-multisite-fails-on-second-site-when-migrating-from-scratch/108559
> Another benefit of using GitHub is that it autosaves what I've written already to the issue.
Maybe this is (another) missing feature of Decidim?
These additional features would definitely help the problem but I still see the process of coming to Metadecidim an unnecessary overhead to bug reporting.
There are other projects (where I'm also involved) that allow bug reporting for developers directly at GitHub and for non-technical members of the community directly at their community site. If the community bug tracker issues are validated, they are moved to the technical bug tracker at GitHub with more technical details. GitHub works as the "master data" of the issues.
The nature of the bug reports reported to the community bug tracker is generally much "simpler" in the sense that it does not go generally further to the technical details. In my experience, they explain the bug more from the user perspective where the GitHub issues can go directly to the technical details.
I feel the same that such "generally described" issues should be kept outside of GitHub and the correct place for those is at Metadecidim.
While I think it's important to keep using Decidim to define the roadmap with the rest of the community, I agree with Antti technical bug reporting isn't best done on meta.decidim.
Let's keep the bug report space here, but I think it was a good thing we keep some flexibility and keep allowing github issues for the more extended dev community.
Conversation with Xabier
@ahu thanks for you comment. I must say that I agree with what @andres said previously. This decision has been taken after a long period of internal discussion. And it is good to open up the debate.
I think it is first very important to note that bug reporting CAN still be moved and discussed on GitHub, it is simply that it needs to be originally reported here. This is a practice that has been implemented on some other projects as well. It has its pros and cons. But there is a trade off we have considered carefully: a) developers are forced to use Decidim (often for the first time), b) there can be an integrated tracking of all bugs, c) we all meet here to improve Decidim and not on GitHub where only developers meet (in a non-free, non-sovereign digital platform). We understand it might be frustrating at first, but we hope the benefits to become higher than the inconveniences.
This being said, we can change this policy in the future or anybody can also push an initiative to change it.
I see what you mean ... for first time comers. Can we discuss giving the ability to report issues directly in Github for developpers already afiliated to the project (us, Antti etc.)?
I guess I'd welcome the feedback of people who already are part of the Github organization and can report issues.
Do @mrcasals @oliver_valls always report bugs using metadecidim or do they file them directly on the repo ?
> I guess I'd welcome the feedback of people who already are part of the Github organization and can report issues. Do @mrcasals @oliver_valls always report bugs using metadecidim or do they file them directly on the repo ?
The idea is exactly that, that all project developers use metadecidim.
I like this idea of reporting to meta.decidim. @virgile_deville, until now we used to report first to meta.decidim except for very technical issues. Now we'll report everything to meta which is not bad. Maybe we should totally disable github issues and link PR directly to meta.dedicim?
Regarding these points:
a) In case the platform would be as competitive for reporting technical bugs, I wouldn't see any problem with this and I believe the change could happen naturally. Forcing people to use a specific tool sounds more like dictatorship (or corporate management) rather than democracy.
b) While I see the benefits from project management side, I just feel very confused currently browsing Metadecidim or report any issues here (compared doing that in GitHub).
I understand that Metadecidim is more than a developer community and I feel it should be kept like that. In my opinion development related bug reporting is not relevant regarding the discussion that happens here.
In my opinion the integrated tool should be GitHub and non-technical users could still leave the unformatted bug reports at Metadecidim.
c) We are talking about bug reporting here. I am not convinced that the average person would participate in a bug report that points to a line of code and suggests...
...a fix.
While GitHub is non-free and non-sovereign platform, you have decided to use that platform for code contributions for this project rather than using a free and sovereign alternative (which also exists).
GitHub also does not prevent you from detaching the issues from their platform and storing them somewhere else using their API:
https://developer.github.com/v3/issues/
Conversation with Carol Romero
Hi everyone,
I agree with what is said, and I also see the pros and cons of using metadecidim as an entry point for bug reporting.
@andres commented an intermediate option that could work: keep open the creation of issues in github, with the commitment that if you create the issue, you also create it in metadecidim and link it. In this way we keep the goal of "eating our own dog food", but we allow whoever wants to report bugs exhaustively can do so with the ease that github offers. What do you think?
Without giving my point of view on the point being discussed here, may you explain why you need to centralize all the issues on metadecidim?
Hi Armand, the main reason is that it is much easier to use a single space to manage bugs. If we keep metadecidim and github at the same time it can happen that the same error is reported twice, as it has already happened. We could also use github as a unique space, but we know the barrier it represents for non-developers.
Conversation with álvaro ortiz
I agree that it will be harder at first to use Meta Decidim instead of Github, but I think the idea makes sense and that ultimately will make developers more aware of Decidim issues that need to improve. So +1 to this change!
I'd like the idea of using MetaDecidim, however it's true that github helps a lot with formatting in order to describe what happens properly.
It would help to have more formatting options (🤔Markdown in comments and description) and more characters in the description (currently limited to 1000).
+1000 to markdown formatting in Decidim! I've already changed the limit of characters to 10000.
That is a nice aspect of this topic and I also feel that developers should be using the system themselves as well. But they should be using it for what it's meant for, i.e. democratic participation.
For technical bug reporting I don't see it is the correct tool for the job. It just adds unnecessary overhead for bug reporting since there is so many different sections here at Metadecidim, as it is a place for general development discussion. In regards of bug reporting this adds many unnecessary steps (sign in => click processes => click report a bug => click report a bug AGAIN => pass the etiquette validator's dummy test of adding unnecessary words to the title => complete all the 4 steps of submitting a new bug/proposal) while they are required to keep all these possibilities in this single platform.
By the way, noticed typos in that comment that I'd like to fix by editing...
Conversation with Oliver Azevedo Barnes
Hello, totally new to Decidim, and interested in contributing as a dev. This is an interesting discussion, I see merits on all the different arguments exposed here. A few questions/suggestions from a newbie:
- have you considered using Gitlab instead of Github, to stay on free/sovereign tooling (as @ahu pointed out, there are good alternatives)?
- how about keeping high-level feature proposals on meta.decidim, and bugs on the code repo? Dogfooding without hampering the dev worklow too much
I can elaborate - actually started writing a huge post, but that would have been impolite =D
Hi @oliverbarnes, welcome to the family! :)
As for your questions:
- Yes, we have considered Gitlab and we don't discard it out for the future.
- Ok, I agree that Metadecidim is not the best place for bug reporting, but how else do we dog fooding? Unfortunately developers don't enter Metadecidim often...
So, here's a proposal:
- For feature requests: we only use Metadecidim.
- For bug reports: non-developers use Metadecidim, devs use Github. BUT the developers enter Metadecidim to discuss/answer the bugs that are created there and, if applicable, create themselves the issue in Github. In this way, from the Product team we don't die either. 😅
> I can elaborate - actually started writing a huge post, but that would have been impolite =D
Please do! :)
In this respect, just a couple of explanatory notes:
- By developers in the comment above (entering to Metadecidim) I mean the current team hired by Barcelona City Council, the tasks of which have a certain scope and end date.
And related to this, a clarification:
Unfortunately, the project does not have an in-house development team (yet). I say this for all of us to be aware that at the moment the capacity to improve/expand the functionalities of Decidim is limited.
So, do we have a deal? lacking here to be able to mention to all the devs-list, as in github : __ )
@carol, we're fine reporting everything (bugs and proposals) to meta.decidim.org
@carol For me, that would be acceptable solution, so that all the technical details would be kept at GitHub and then only the description part at Metadecidim linking to the GitHub issue. I'm OK reporting it in two places that way.
i agree too
Add your comment
Sign in with your account or sign up to add your comment.
Loading comments ...