search

sugarlabs / browse-activity

Sugar activity to browse the internet; WebKit on GTK on Sugar Toolkit
GNU General Public License v2.0
8 stars 44 forks source link

Point bugs to Github Issues #127

Open chimosky opened 1 year ago

chimosky commented 1 year ago

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.

quozl commented 1 year ago

You've pointed to Browse issues. Are you sure that's what you want?

chimosky commented 1 year ago

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.

quozl commented 1 year ago

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?

chimosky commented 1 year ago

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.

chimosky commented 1 year ago

@quozl do you still have any reservations about this?

quozl commented 1 year ago

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.

chimosky commented 1 year ago

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.

quozl commented 1 year ago

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.

chimosky commented 1 year ago

What would you suggest moving forward? We do need a way to report issues.

quozl commented 1 year ago

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.

chimosky commented 1 year ago

App metrics seems futile for Sugar but I understand the idea, maybe a Report an issue that's part of the settings that points to our matrix channel?

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.

quozl commented 1 year ago

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.

chimosky commented 1 year ago

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.

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.

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.

Agreed, which is why pointing to our matrix channel is a good idea.