Jump to content

Improve 'Support over Forum' situation


chwe

Recommended Posts

23 minutes ago, Igor said:
57 minutes ago, Werner said:

What about simply redirecting  "Armbian build framework" to https://github.com/armbian/build as all stuff regarding the building process, script and so on is discussed (or should be at least) discussed there?


Perhaps. @zador.blood.stained?

Not sure about this.

- the second tab on Github project is called "Issues", not "Discussions" or "all stuff", and it has "Open"/"Closed" statuses more suitable for tracking actual bugs/issues than discussing build script usage

- this would make it impossible to easily move framework related discussions from the forum to the right place

Link to comment
Share on other sites

14 hours ago, zador.blood.stained said:

Not sure about this.

- the second tab on Github project is called "Issues", not "Discussions" or "all stuff", and it has "Open"/"Closed" statuses more suitable for tracking actual bugs/issues than discussing build script usage

- this would make it impossible to easily move framework related discussions from the forum to the right place

I think we should not take take that with a pinch of salt just because it says "Issues".  Don't get me wrong, I totally get your point, but if the mix of issues with discussions is either here in the forums (just take a look over there) or at Github issues does not make a big difference. At github discussions can be labeled as those at least as every new topic there needs a review in first place.

 

What about this as a compromise between both:

- Rename "Armbian build framework" to "Armbian build framework - Discussions" and

- create another subforums Armbian build framework - Issues" which redirects to Github

 

 

 

At the bottom line there is no perfect solution for this because there are always and always will be users which are either inexperienced, creating topics at the wrong place by accident or are just trolls. Unfortunately there is no other way than cleaning up behind. That's the curse of all forum operators.

Link to comment
Share on other sites

5 hours ago, Igor said:

Another option to limit pressure on support is by enforcing forum payment system. System is here, it's highly integrated in forum ... and it works. Not exactly to charge for support but to return a pressure back.

I'm not a fan of this idea.. For sure it would reduce the support 'pressure'.. But I think it may also scare away the good people..

 

most of the support questions can be solved with google *fill in your preferred search engine*.. maybe we should encourage people more to use it.

tags could make sense.. e.g. in the sunxi.. where people must decide between H3/H5/H6 flag them with different colors and make H6 red.. :P

this would simplify things a bit..

 

On 1/16/2019 at 6:15 PM, Igor said:

Yes, prefixes can be optional or enforced.

can we enforce an other input field where they've to post their armbianmonitor link? :P at least for those opening a thread.:D

 

Link to comment
Share on other sites

Just now, chwe said:

But I think it may also scare away the good people..


Agree. This has to be used very carefully. If at all.

 

1 minute ago, chwe said:

can we enforce an other input field where they've to post their armbianmonitor link?


That's a good idea. I'll check if that is possible.

Link to comment
Share on other sites

1 hour ago, Igor said:


 

 


That's a good idea. I'll check if that is possible.

I am torn about this. For various you may not be able to generate such a link. Like network issues (you still get the output but not the special link), I/O issues or boot issues.

 

 

Link to comment
Share on other sites

12 hours ago, Werner said:

For various you may not be able to generate such a link.


Agree. It's a step forward if there is a field ... it has to be optional and we have solved this problem.

Link to comment
Share on other sites

15 hours ago, Igor said:

Plus adding this plugin

https://invisioncommunity.com/files/file/9042-auto-lock-topics/

to entire Technical support question with locking everything that older than 90days? 

This would make sense in a combination with various restriction for creating a new topics (adding armbianmonitor -u).

Are there that many older topics that getting exhumed? Not sure if possible with Invision without addon, I know that worked in vB years ago but what about simply limiting the number of visible topics by age up to 90 days as default?

Link to comment
Share on other sites

This is how it will look like when enabled - is there anything odd that has to be changed - beside texts - some native speaker should check that. Tags are limited to one (1), legacy or mainline.

Spoiler

new-topics-tech-support.pngnew-topics-tech-support-display.png

 

45 minutes ago, Werner said:

what about simply limiting the number of visible topics


We also want to prevent topic bumping. Perhaps this closing time could be longer than 90 days. Let's set it for 1y and adjust in the future.

Link to comment
Share on other sites

Looking decent. Nothing odd so far.

 

Quote

We also want to prevent topic bumping. Perhaps this closing time could be longer than 90 days. Let's set it for 1y and adjust in the future.

As from my experience topics usually are bumped actively during the first days till maybe weeks, but not over month. The situation here might be different though.

Link to comment
Share on other sites

for whatever reasons pinned threads are hidden and you had to click on them to get they appearing..

Untitled.thumb.jpg.0d3fdfdfaa5ed9e08afc9504e5d74170.jpg

are others also affected?

 

3 hours ago, Igor said:

This is how it will look like when enabled

I would write armbianmonitor -u . Is it possible to combine it with a checkbox (can't provide armbianmonitor) and make one of them mandatory? some slight force to fill it in.. ;)

Link to comment
Share on other sites

8 minutes ago, chwe said:

for whatever reasons pinned threads are hidden and you had to click on them to get they appearing..

 

They are hidden if there is nothing new in them. This can be set per forum.

8 minutes ago, chwe said:

I would write armbianmonitor -u . Is it possible to combine it with a checkbox (can't provide armbianmonitor) and make one of them mandatory? some slight force to fill it in..

 

Probably. I'll try.

 

It's already enabled in Technical support section. Auto-lock will follow - i did testing in recycle bin and it seems to work properly.

Link to comment
Share on other sites

New features and restrictions for "Technical support" area:
 
 1. Validating users, those who just register are unable to reply to topics. They are forced to open a new topic.
 2. All users have to accept conditions (cookie last one day): 1. Call to use docs and search 2. Call to support us 3. Call to provide info
 3. Each time a topic is created, you need to add: armbianmonitor and accepty several conditions

 4. Auto lock topics is now set to 365 days, pinned and featured are exempt, ... and it will take a few days before locking will be completed

Link to comment
Share on other sites

19 minutes ago, lanefu said:

For board maintainer it could literally be one board ?  Extreme example: just opi one but not lite?


If you choose a little more complex board, then yes. But IMO Opi One does not need a dedicated maintainer. In this particular case, both would be ideal to make some relieve on me.  But how to write this into the application?

Link to comment
Share on other sites

8 hours ago, Igor said:
11 hours ago, lanefu said:

For board maintainer it could literally be one board ?  Extreme example: just opi one but not lite?

 

Updated with wanted list:

 

Capture.PNG.d9da506a36b47f850dc3d779a3cd9a4d.PNG

at least not as a board maintainer.. :P But anyway.. I don't plan to maintain a board in the next months.. (it's enough to do some CSC work for the R2 and some initial board bring up for the rockpi - and if I still want to trash more time there's a camera driver for rockchip bsp waiting.. :D

 

 

Link to comment
Share on other sites

3 minutes ago, chwe said:

at least not as a board maintainer.. :P But anyway.. I don't plan to maintain a board in the next months.. (it's enough to do some CSC work for the R2 and some initial board bring up for the rockpi - and if I still want to trash more time there's a camera driver for rockchip bsp waiting.. :D


Application is disabled until text is polished out, than if will be limited only by content count, days as a member, ...

 

Hacking and bringing boards to life is the funniest part :P But somebody, besides me, has to be accountable also for the not so fabulous and interesting work :( Not to mention dealing with idiots/spam on all levels, which came with the project recognition.

Link to comment
Share on other sites

On 1/20/2019 at 3:46 PM, Igor said:

A bit automatized call for moderators revitalization and board maintainters. Need some native speaker/idea check:
https://forum.armbian.com/staffapplications/

 

Hey @Igor  Here's an alternative version of the board maintainer text.   Feel free to tune as you see fit.

https://gist.github.com/lanefu/7c54235264d0f8e442c8799249220bf6

Link to comment
Share on other sites

On 1/20/2019 at 12:46 PM, Igor said:

A bit automatized call for moderators revitalization and board maintainters.

 

I think one of the challenges with board maint is that github's issue tracker isn't very good at tracking issues - it's basic and good for small projects, but the scale/scope of armbian is outgrowing what github is intended for there.

 

OpenWRT uses Flyspray, pfSense uses Redmine (which is also good for project management) - MantisBT is ok, and like Flyspray easy enough to self host and maintain - and there is always Bugzilla, but that's one I would shy away from due to it's age and complexity to deploy and maintain.

 

Any bugtracker is going to need to have some learning curve, as they have their workflow management...

 

Consider this...

 

Chip Vendor -> Chip Verison > Board Vendor -> Board Version - or putting it another way...

 

AllWinner -> H5 -> four or more Board Vendors -> each having multiple boards...

 

See the tasks at hand? And we don't even consider the upstream from various sources (mainline, ubuntu, debian, along with the Linux-Sunxi, Linux-Meson, and other upstreams from Vendors and Chipsets)

 

Keeping track of all this is somewhat of an Augean Task - not even Hercules can shovel that much *hit, so a lot gets put off without full time support, and it all falls apart in the end.

 

And tracking issues with forum posts is an impossible task outside of lightweight community self-support, but that doesn't cover major issues across the various upstreams.

Link to comment
Share on other sites

3 hours ago, sfx2000 said:

And tracking issues with forum posts is an impossible task

:( Yes, I've had things slip because I looked at a post, then it got buried...  It's not the best way.  I've been trying to find some project management tools (for my own stuff as well as this)

Link to comment
Share on other sites

I was thinking about a (dedicated) bug tracking system as well, but for new users it might be difficult to get a hang for it. Though besides Github and forums there would exist a 3rd page that needs maintenance...

Would be interesting if the user database can be synced between one of these bug tracking systems and the forums so nobody as to re-register.

Another that came to my mind was using Github as bug tracker for issues with the provided images. But I think this may have more disadvantages than other alternatives. 

Link to comment
Share on other sites

1 hour ago, Werner said:

Though besides Github and forums there would exist a 3rd page that needs maintenance...


Further fragmentation will create more confusions at the users side. I am skeptical if, after we wasted a time to learning and embracing new habits, will there be anything better? And we will certainly not loose bugs which we have no intention to deal with. 

Link to comment
Share on other sites

3 minutes ago, Igor said:


Further fragmentation will create more confusions at the users side. I am skeptical if, after we wasted a time to learning and embracing new habits, will there be anything better? And we will certainly not loose bugs which we have no intention to deal with. 

Yes, you are probably right. 

A bug tracking system would make sense only if it is implemented within the forums properly I guess.

 

Anyway I was just thinking out loud ;). It is hard to find a good solution because everything will have advantages and disadvantages. It is about to find the way with the least amount of criticism.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines