Point bugs to Github Issues #127
Conversation
There was a discussion regards this and the board decided to point bugs to our Github issues instead of not having a mechanism to report issues. Signed-off-by: Chihurumnaya Ibiam <[email protected]>
|
You've pointed to Browse issues. Are you sure that's what you want?
|
Yes, I did that so redirecting the issue to the right place if necessary would fall on us instead of who's opening the issue. |
|
I guess I don't understand. What you say could also be the case if the issue was created in the Sugar repository. What's the benefit of using Browse activity as a triage point?
|
Yes it could also be the case if the issue was created in the sugar repository, there's really no benefit to using Browse activity as a triage point but I did it as that's where the bugs link is found hence I just used it. |
|
@quozl do you still have any reservations about this? |
|
Yes. I don't think a link to Browse issues is helpful on the Browse activity default page, because we don't have enough developers to triage and handle issues. Sugar has the Social Help function that could be redirected to something more appropriate, again assuming you have a team willing to handle the legitimate and spam input. |
|
Given that social help was decommissioned years ago, I doubt it's a good idea to direct queries there as no one really uses it anymore. For sure we don't have enough developers but opening an issue here gives visibility to the developers we have. |
|
It is inviting trouble. The user experience will be an overall
negative. They will have to go through the GitHub account creation
barrier, then they have to explain their problem, then developers will
tell them why they are wrong.
Also Browse is an unlikely activity in which to find a feedback
facility.
|
|
What would you suggest moving forward? We do need a way to report issues. |
|
Concentrate the users and developers into one place. i.e. discord or mailing list. Expect developers to either fix what is reported, or if there is no time to fix immediately then developers to create issues in GitHub against the repository that will be fixed. The model used by phone apps has caught on with the user community; of leaving feedback in the app store, or just switching to a different app. App metrics is the new feedback path. Check with Lionel how he gets Sugarizer feedback. |
|
App metrics seems futile for Sugar but I understand the idea, maybe a Browse seems like a great place to implement this as a user would most likely open browse to report any issue as that's how they'd access the internet. |
|
The Social Help feature in Sugar is available from Frame and is contextual, and sits over the UI, whereas Browse is an activity. There's a Social Help URL setting that can be changed for a Sugar release once a landing page is set up. Having watched several teachers and lecturers, the most likely winning support solution is grabbing their phone, taking a picture of the display, and posting it on Slack. They first need to establish a communication path and relationship with developers; they don't need a ticketing system or issue report form. |
I think we should change that to point to our matrix channel as that's one of the best way to reach any sugar developer right now.
Agreed, which is why pointing to our matrix channel is a good idea. |
There was a discussion regards this and the board decided to point bugs to our Github issues instead of not having a mechanism to report issues.
@quozl kindly review.