Jump to content

Improve 'Support over Forum' situation


chwe

Recommended Posts

10 minutes ago, Werner said:

 

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

 

 

"...to create less fragmentation" I have to add ;)

 

8 minutes ago, Igor said:

Interesting. I will take a look at this later this day.

Link to comment
Share on other sites

Looking decent. "Departments" could be the current breakdown of the current Technical support forums. To say Allwinner A20, Allwinner H2 & H3 and so on...

This seems to be free of charge as well so we won't lose anything by just giving it a try.

Link to comment
Share on other sites

So what exactly is the dividing line we want to achieve between what belongs in a forum and what belongs in a bug /issue tracker?

 

How do other projects do it?  Any comparable projects we can look at for a case study?

Link to comment
Share on other sites

On 1/25/2019 at 2:20 AM, lanefu said:

So what exactly is the dividing line we want to achieve between what belongs in a forum and what belongs in a bug /issue tracker?

 

How do other projects do it?  Any comparable projects we can look at for a case study?

Any open source project will do for comparison I guess.  

 

The first thing that came into my mind was Filezilla. I took a quick look and they are using forums for support and Trac for issues. I am not sure how this subdivision works out for them as an end-user you may not know if you actually found a bug or just acting stupid or whatever.

In comparison we would divide between build-script (issues/support) and the provided pre-built images (issues/support).

 

The next project was LibreOffice. On their help you can choose between asking a question (about a softwares' function and so on), report a bug and report feedback/enhancements. The last two things are handled by Bugzilla, for questions they are utilizing some kind a forum.

So basically the same subdivision Filezilla is using and coming up with the same question as above.

 

Of course these are two randomly chosen open source projects and a quick look only.

 

Link to comment
Share on other sites

I know. Though I do not think that the similarity of what the project is all about is important in this case.  All have to deal with development, bug reports, user support and off-topic in a way or another.

Link to comment
Share on other sites

1 hour ago, lanefu said:

Ya I kind of meant what's an open source project similar to armbian and how do they handle development vs community interaction...etc

well which project do you think?

Let's look at a few which have some similarities.

Retropi:

Quote

We use the Issue Tracker on our GitHub Project page for tracking bugs and enhancements. Please keep support / help requests to the forum. If unsure, please use the forum first.

 

Raspian:

https://www.raspberrypi.org/forums/viewtopic.php?t=208814#p1291227

Quote

That rpi-distro/repo issue tracker is for issues with raspberrypi.org packages. I don't think we've touched virt-viewer, so that raspbian bug tracker is the correct location. It may take a while for plugwash to find time to look at it though.

 

OpenWRT:

https://openwrt.org/bugs

Quote

Bug or no bug?

In case you are unsure if what you found is a bug, or if you have other issues that are not bugs, please use the forum, IRC or mailing list.

Issue tracker

Report bugs pertaining LEDE core functionality and device support using our issue tracker.
If the bug is about a secondary package in the feeds you need to open an issue in the package feed's issue tracker instead.

If you are unsure, please use the Packages tables to know where you should report the bug.

 

DietPi:

mostly forum, a bit on GitHub

________________________________________________________________________________________-

There's no project which is 100% similar, otherwise one of them would be obsolete.. :D A few of them scale bigger, some have a different focus. Some ideas:

manual transfer: as soon as a experienced user/mod/maintainer realizes that the forum post is related to an issue he opens it, summarizes it and links to the related forum post. It's time consuming but we would keep track on all those bugs we spot through forum posts.

As soon as we have an issue tracker outside forum or github, we've to train people once again to use it.. we've to maintain it.. and those not willing to register somewhere will still use the forum for that. The only idea which comes to my mind is either one on a well established platform so that the average user has it anyway (e.g. github) or mailing-list (I assume most people will still have a mailaccount :ph34r::lol:) but not sure if maintaining a mailing list would solve any problem - I would assume not.

 

Maybe we can implement a bug Tag? once figured out that a thread is bug related mods/admins/devs could just add the bug tag to the related post/thread? Keeping an eye on threads with such a tag might be easier.. Still, the tag has to be removed once the bug is fixed, but it could be a starter.

 

Link to comment
Share on other sites

 
DietPi:
mostly forum, a bit on GitHub
________________________________________________________________________________________-
There's no project which is 100% similar, otherwise one of them would be obsolete.. A few of them scale bigger, some have a different focus. Some ideas:
manual transfer: as soon as a experienced user/mod/maintainer realizes that the forum post is related to an issue he opens it, summarizes it and links to the related forum post. It's time consuming but we would keep track on all those bugs we spot through forum posts.
As soon as we have an issue tracker outside forum or github, we've to train people once again to use it.. we've to maintain it.. and those not willing to register somewhere will still use the forum for that. The only idea which comes to my mind is either one on a well established platform so that the average user has it anyway (e.g. github) or mailing-list (I assume most people will still have a mailaccount ) but not sure if maintaining a mailing list would solve any problem - I would assume not.
 
Maybe we can implement a bug Tag? once figured out that a thread is bug related mods/admins/devs could just add the bug tag to the related post/thread? Keeping an eye on threads with such a tag might be easier.. Still, the tag has to be removed once the bug is fixed, but it could be a starter.
 
Ya you nailed what id been thinking.

Some pretty big projects work out of github. So i think learning to master its functionality and even look at github bots if needed is a great path forward

If the process above is properly captured in documentation and a clear policy for moderators to guide forum issues into github would be a huge step in the right direction without forklifting things to a new platform.

I tried design a process a few years but, but i got it backwards and was trying to redirect issue dialog back to the forums.

Sent from my SM-G950U using Tapatalk

Link to comment
Share on other sites

On 1/25/2019 at 2:20 AM, lanefu said:

and what belongs in a bug /issue tracker?

 

Ideally/must: we want to deal only with a problems that are a consequence of our actions. General Debian problems and help on users solutions have to be filtered out. I don't want to see them not even close to the bug tracker and TBH not even on a forum. At least not in any official areas. I am aware that many people have no idea whether issue is Armbian or generic Debian and sometimes I have to think as well. Only a few people jump straight to Debian bug tracker list while other simply expect a few people (they don't even ask that) that work on Armbian is going to fix all (their) (upstream) problems. 

 

Setting a clear line what can be considered an issue is a first problem we have to solve.

 

On 1/26/2019 at 7:28 PM, chwe said:

we've to train people once again to use it.. we've to maintain it

On 1/26/2019 at 7:28 PM, chwe said:

mods/admins/devs


My biggest concerns goes here. Relation between people that want something and people that do something is extreme and even for lighter tasks, there is no interest to help: https://forum.armbian.com/staffapplications Having a bug tracker without additional help will only put more pressure on the usual suspect which means all this can can be one step forward and two back.

Let's try to figure out how to reinforce the crew.

 

33 minutes ago, Igor said:

Setting a clear line what can be considered an issue is a first problem we have to solve.

 

If we limit who can open a ticket (groups: moderators, developers, angel) in a system as this https://invisioncommunity.com/files/file/9085-database-tickets/ a problem is almost solved. We only need people to solve those issues ... :) 

Link to comment
Share on other sites

5 hours ago, Igor said:

If we limit who can open a ticket

I see some structural challenges here.  One is a perceived hierarchy perhaps keeping some people from mentioning issues (to be honest we already have that problem, I've had small issues in images for months before someone pointed it out).  If we take this route, then the forum has to be as open as possible to general user complaints.  Restricting access results in a shrinking of community in general, it's a difficult position because in order to grow the community you have to allow "know-nothings" to ask questions and hopefully become "know-somethings".  We also need to find a good way to appeal to a more diverse user base, application wise. 

 

People like @Larry Bank and @sgjava have done some great work, but our willingness (and ability) to support ends with server-type environments (nothing wrong with this, but it is a *very* limited niche of people who can contribute to that specific task thing)

 

@JMCC is doing great work with media, if we can roll at least some of what he's doing into the build script it would be fantastic (I was thinking we should package his scripts as part of a board or family specific armbian-config menu)

 

So we have the groundwork for IoT and Multimedia applications, which will make our little Linux project more interesting for the general public, especially if we can make these things somewhat standard, we get more users.  from those users, some programmers/maintainers/mods/etc will show up.  The issue is the age old one of humanity:  Talent and interest are hard to find together. If the vendors are not willing to help, despite the value, then we need to move an insane number of people through the forums to snag ones that are able and willing to contribute.

 

I think we do need to approach the "slimming down" of our boards a bit more carefully.  This is something along the lines of @tkaiser's comments about this being a project for us, with our help to everyone else being a happy side-effect.  If we are not overwhelmed, we make better things, the community benefits.  If a high-level user wants their board supported badly enough, they will work to support it (Me with Tinker Board)  We need to add a "maintainers" list or something similar, this is for one simple reason:  boards with no maintainer need to be put on probation.  A stronger definition of individual roles (not in a leadership sense, just in a contribution sense) will help as well I think. 

If a board has no maintainers and no vendor support, it should be "CSC'd", with a list on the website with "looking for maintainers"  I would propose we not make images for those boards available on the download page, allow people to build them if they want.  That alone filters who would be asking questions.

 

So, for boards:

 

Each board entry should include 2 additional fields:

  • Maintained-by  (Member or members)
  • Vendor-supported (Does the Vendor give Armbian anything more than just a couple boards?  I include technical support here)

So Tinker Board and Le Potato would look like:

  • supported-by: tonymac32
  • vendor-supported: yes  (or we could make tiers, everything from boards on demand, technical support, direct code contribution, money)

 

For Member-contrubtors:

 

  • boards
  • hosting
  • documentation
  • etc

So Igor (sorry if I massively under-represent:

 

  • Build Script Author (obviously multiple people can have each tag)
  • Web Admin
  • Build Hosting
  • Family-Allwinner
  • Family-Freescale
  • Documenter
  • etc

I can expand on this later in a specific thread since it covers a wide topic matter.

Link to comment
Share on other sites

5 hours ago, TonyMac32 said:

Each board entry should include 2 additional fields:

  • Maintained-by  (Member or members)
  • Vendor-supported (Does the Vendor give A

Guess why Igor and TK had in their signature, do not write me a PM for xyz. You would basically force exactly that.

 

5 hours ago, TonyMac32 said:

in a shrinking of community in general,

here you raise the unspoken question, is it for everyone who has $ 25.- over/left to spend for an order in China ?  Without a clue about Linux?

 

@Igor , wrote some posts ago - a person who spent $ 25.- is not willing to pay for support - but frankly ask you to help them with their problem. To come back to my line above, to whom do you want to be attractive and why?

In other words, we have no roadmap and a lot of others;  like other projects already have. We wrote tons about this in the forum... but we have never changed or written down unless Igor did:

https://forum.armbian.com/terms

https://forum.armbian.com/guidelines

This is one of the reason why I once upon a time started: "fix the basic"

 

Bugtracker... you can have your own once you spot something you want to fix, easy to maintain, no additional load: https://www.taskcoach.org/  KISS

 

Link to comment
Share on other sites

1 hour ago, Tido said:

Guess why Igor and TK had in their signature, do not write me a PM for xyz. You would basically force exactly that.

Irrelevant.  If someone doesn't recognize the main contributors without such a tag already they'll be too dense to figure it out even with that extra help.  It's a tracking tool, far more effective than guessing.  The entire point is, if the board number is reduced to both vendors and users who give a damn, then we can focus more completely on the task at hand, the quality and consistency of the thing. 

 

Board hierarchy  would go like this:

 

Is a community member willing to "own" it? y/n

Does the vendor support it on their side? y/n

Does the vendor help Armbian in some way (either with the board or generally)? y/n

 

1 hour ago, Tido said:

a person who spent $ 25.- is not willing to pay for support - but frankly ask you to help them with their problem

Ignore them, I've seen an uptick in the Amlogic and Rockchip forums of community helping each other.  Necessity is the mother of all invention.  See if it is a legit build system problem, if not, politely say "sorry I can't really help, that looks like a use-case issue" or something similar, and move on.  Or simply ignore it.  The problem I'm seeing develop here is 150% typical for engineering/software/technical sales types:  They expect the user to know too much, and get grouchy when they don't.  Asking questions is almost never done in malice, don't act as though it's a criminal act.  Someone saying they got ignored on the forums is infinitely better than someone saying "I asked a question on the Armbian forums and that Tido guy called me an idiot and said I was wasting his time" (example only, but you get the point). Rules are good, but ignoring unless you have the time is more effective.  Making people fill out a questionnaire before posting a question is also bad, but until now I hadn't seen enough of a reason to complain about it.  Ignore them.  It's honestly quite simple.  They get noisy toss the rules at them, and we live peacefully.  Any of us answering questions is entirely voluntary, including Igor.  Treat it as such.

 

1 hour ago, Tido said:

Bugtracker... you can have your own once you spot something you want to fix,

That was my plan in any case.  I need one for my personal projects anyway.

 

Link to comment
Share on other sites

4 hours ago, sgjava said:

We use it at work and you become a slave to the process instead of programming

sounds like a perfect definition of SAP... :ph34r::lol:

 

6 hours ago, TonyMac32 said:

We need to add a "maintainers" list or something similar, this is for one simple reason:  boards with no maintainer need to be put on probation.  A stronger definition of individual roles (not in a leadership sense, just in a contribution sense) will help as well I think. 

I think the maintainers list flies around in our heads since a long time (couldn't find the thread anymore, or it was on pm.. no idea, probably in the project aims thread or here)..  A starter could be SoC maintainers instead of board maintainers... e.g. every patch touching RK3399 needs at least your approval to be merged.. every H3 related needs igors approval etc. the more you work with a SoC, the more you know its faults.. and if this is a real concern:

50 minutes ago, Tido said:
6 hours ago, TonyMac32 said:

Each board entry should include 2 additional fields:

  • Maintained-by  (Member or members)
  • Vendor-supported (Does the Vendor give A

Guess why Igor and TK had in their signature, do not write me a PM for xyz. You would basically force exactly that.

we could have 'who has which board list' private so that patches can be redirected to those people without floating their inboxes with 'support questions'.. but I'm quite sure it happens anyway.. people will notice who's doing such stuff and stalk them privately to solve their issues.. It doesn't need much to figure out who's good in *random topic*...

 

For the 'individual roles'.. I think those roles aren't that clear.. :P most devs do u-boot, kernel and rootfs related stuff (and when needed also buildscript related stuff).. A proper review policy might help here.. (e.g. when touching nand-sata install @zador.blood.stained has to review it)..

 

12 hours ago, Igor said:

General Debian problems and help on users solutions have to be filtered out. I don't want to see them not even close to the bug tracker and TBH not even on a forum.

well they will be here.. to sort out if it's our issue or a debian issue isn't always easy.. best would be that such solutions would then end in a tutorial in the tutorial section.. as some sort of a 'contribute back', we might encourage people more to write such tutorials out of the help they got.

 

1 hour ago, Tido said:

Bugtracker... you can have your own once you spot something you want to fix, easy to maintain, no additional load: https://www.taskcoach.org/  KISS

someone able to fix a *random issue* might probably don't even spot it.. cause not reading every thread/post here.. things get out of track.. or the one catches the bug isn't able to solve it, but someone else is.. it's part of the basics things to keep track of the bugs your project has.. the 'nicest' web-page, project goals etc. is worthless without images of good quality coming out from the buildsystem (and the updates we provide over apt). Keeping the project maintainable is a basic requirement..

Link to comment
Share on other sites

28 minutes ago, chwe said:

sounds like a perfect definition of SAP..

Don't speak of The Program That Must Not Be Named. :ph34r:

 

28 minutes ago, chwe said:

A starter could be SoC maintainers instead of board maintainers...

That's doable, with the understanding that TV boxes don't fit.

 

29 minutes ago, chwe said:

every patch touching RK3399

lol which RK3399?  :lol:

 

30 minutes ago, chwe said:

For the 'individual roles'.. I think those roles aren't that clear.. :P

 

True, but the primary ones so we can at least get some reviews in place, and get a sense of how big a chunk of the pie any individual is taking on.

Link to comment
Share on other sites

On 1/28/2019 at 5:32 PM, sgjava said:

This is really the only method that really works


:) True.

 

On 1/28/2019 at 5:12 PM, TonyMac32 said:

If we take this route, then the forum has to be as open as possible to general user complaints.


Restrictions should be here to guide users to keep the data in a useful form. To save us some time. If they are wasting our time by purpose or by laziness, they are refused and they have to understand why they have been locked.  If their topic is publicly refused when added without having armbianmonitor -u they will eventually start adding it and I am sure there will be a few who will never follow - we can handle moving those few into general areas. I am not afraid of those but the bulk. 
 

On 1/28/2019 at 5:12 PM, TonyMac32 said:

I think we do need to approach the "slimming down" of our boards a bit more carefully. 


Agree. This topic is also getting messy with all kind of problems. Not just forum related. It is getting difficult to stay on track. Shell we cut it down to separate topics to get a clearer picture over the problems.  We all can't do with all at once. One shell take this, another shell take that ... 

 

Technical support area was initiated to catch some feedback, to find bugs, to hear the community. Our interest remain unchanged, while relation between contributors and users got out of control. Users wants that we solve them all kind of problems and work on their solutions. On our behalf. That is ofc not possible nor acceptable. Here I want to draw a line. How to tell them this? How to punish those who are breaking those rules? Selling viagra pills and not comply is spam on the same level.

 

This part of a (spam) letter, that I recently got in private is saying:  "I am a startup with no money, which projects like armbian allow us to exist and get started with almost zero expenses." If would not get mad if they would at least not waste my time. Those are not so rear and those need to be limited. I am aware that it can't go without collateral damage. Beside this - in Technical support aka bug tracker we don't want to see:

 

- 3rd party board

- 3rd party hack

- not official builds

- beta builds

- development builds

 

Do we need to add more tags than mainline, legacy, solved?

 

Since we want to catch bugs and not solve users problems ... shell we rename the entire section to Bug tracker? @zador.blood.stained mentioned we could open a new subforum without restriction named something like »Supported boards that doesn’t boot at all«, while keep armbianmonitor -u mandatory for the rest. Other tickets are removed. What about "validating can’t make replies to the topics" which is currently enabled in this section? Does it makes any sense?

 

When armbianmonitor -u is not there, topic is left as is, only locked.  Does this mean the forum is not open enough? 

Another idea is to move move common issues to community section, which we shall also do something about.

Link to comment
Share on other sites

6 hours ago, zador.blood.stained said:

I think you meant "expect the user to read and not just mindlessly tick checkboxes that prevent them from posting their question"?

 

That's a separate issue, but it lies in the reality vs. what we would like to see be true.  The simple reality is you can't force people into line without draconian policy/rules/etc that will choke off the community in general.

 

Now, if it were possible, I would say, along some reorganization lines as Igor posted, that we have a "select your board" drop down requirements for the Support subforum, and if we can go even further, sort them appropriately by that tag.  Then it gets easier, we only have spammers posting in whatever the first board on that list is.  ;-)

 

7 hours ago, Igor said:

Agree. This topic is also getting messy with all kind of problems.

 

Well, the forum is the part people see above ground, a lot of its issues relate to the roots, so it's bound to get complicated.  For example, WIP/CSC's having downloadable images on armbian.com results in user questions, which increases our support traffic for boards we obviously don't find interesting enough to support directly.

 

7 hours ago, Igor said:

How to punish those who are breaking those rules?

Ignoring them is somewhat effective, but like I said above, making a single part of the forum a "gated community" with curated/controlled input should make it so stuff like that can be ignored with a documented reason, without necessarily causing any collateral damage.  And of course keeping boards to a minimum or at least defining what the core boards are should help as well. 

 

8 hours ago, Igor said:

When armbianmonitor -u is not there, topic is left as is, only locked.  Does this mean the forum is not open enough? 

My thoughts on this fall more into the perception and the actual scale of the project.  The act of imposing regulation and setting a bar is viewed as pretentious or exclusionary by the human psyche in general.  That's not necessarily a bad thing, however it's being introduced into a space that was previously open to admittedly "too free" of discussion.  Is it possible to sort posts automatically by tag and then by age?  At that point, a fully filled out questionnaire (with a check so that http://Idontfillout.form won't be accepted ;-) ) would receive a tag that puts it at the top of the non-pinned pile, and above anything that skipped a step.  That simple feedback of basically demoting the content instead of downright blocking it should passively take care of the issue, and if someone gets noisy a mod can point out their stuff is under all the properly filled threads because it wasn't done correctly.  I'd guess there'd have to be some sort of qualifier based on age for when that sorting stops, otherwise the first improperly filled out post would be on page 12 or some nonsense.

 

 

Link to comment
Share on other sites

10 minutes ago, TonyMac32 said:

Then it gets easier, we only have spammers posting in whatever the first board on that list is.  ;-)

call the first one "I don't care, I only trash everyone's spare-time" :ph34r:

 

The thing with restrictions is.. People can spend an amazing large time to fool the restriction tool compared to think that those restrictions have a reason... Not sure if escalate those 'restriction-tool' is the way we want to go... Just getting ignored might be the most effective one.. Every tool we add to the forumsoftware opens just more workload (e.g. fear that all of those tools still work after a froum update etc.).. Configuration which isn't properly set/explained and ends then in such threads:

 

even if igor doesn't want to have more 'not bug/armbian related questions' it might help to have a general linux/debian questions subforum which is also named this way.

E.g.:

 

 

and probably a few more if I would read more stuff there are not really armbian related questions.. I understand why those people are here.. Maybe we should give them some room to keep the tech. support subforum as clean as possible without much efforts..

Link to comment
Share on other sites

15 minutes ago, chwe said:

Maybe we should give them some room to keep the tech. support subforum as clean as possible without much efforts..

That was part of the reason I asked to split the hardware hackery from the general discussion, since it has relevance to SBC's but not specifically to Armbian a lot of the time, and takes up space.

 

16 minutes ago, chwe said:

Not sure if escalate those 'restriction-tool' is the way we want to go..

 

That's kind of my thought.  Look at formula 1 racing and see the ways they cheat, it's human nature I think, when any kind of restriction is in place, it is a challenge to overcome.  Increased control results in an increased effort to defeat it, which needs more control, until things fall apart.

Link to comment
Share on other sites

1 hour ago, TonyMac32 said:

Look at formula 1 racing and see the ways they cheat


Agree. Technical obstacles and cold rules are not enough. All measures together will also not make the problem go away, but it can make it manageable.

 

Perhaps this can be solved rather with better oriented communication? Let's say we want raise awareness. Forum has some sort of ads system, which is not used. There, we could run rotating messages: 


# reporting a bug without logs will be ignored

# technical support is volunteer based

# if you care for our time and provide all necessary info ...

# make sure you open topic in a right place
+ more creative tweaked by @chwe :D

 

In that case, this
 

2 hours ago, TonyMac32 said:

it's being introduced into a space that was previously open to admittedly "too free" of discussion

 

become less problematic.

 

1 hour ago, chwe said:

to have a general linux/debian questions

 

Absolutely. Here we get to the community section, where I already proposed to move "Common issues" which has actually that part of the content, beside those which is in peer to peer.
 

2 hours ago, TonyMac32 said:

Is it possible to sort posts automatically by tag and then by age?

 

No, at least not OOB. We can probably add some URL checking if we have a link to logs or not, but again this can easily be hacked ... 

 

2 hours ago, TonyMac32 said:

WIP/CSC's having downloadable images on armbian.com results in user questions


Self-build, beta and 3rd party builds remains outside our control. IMO those has to be routed to development forums, which should remain unrestricted.

 

And again, here we need telling messages over and over again:

# seeking end user support for development builds is not permitted/wanted/desired

# WIP (work in progress) images are available for testing purposes only. End user support questions will be ignored.

# community supported configurations might not be related to Armbian. Use this forum.

 

Fine tuned communication (which needs to be prepared) + light restrictions (logs are must in bug tracker areas + perhaps a board selector and sub forum without any restriction for boards that doesn't boot)?

Link to comment
Share on other sites

2 minutes ago, Igor said:

IMO those has to be routed to development forums, which should remain unrestricted.

Agreed.

 

3 minutes ago, Igor said:

Fine tuned communication (which needs to be prepared) + light restrictions (logs are must in bug tracker areas + perhaps a board selector and sub forum without any restriction for boards that doesn't boot)?

I think the logs are a good call,  if we have SoC sub forums in "community forums" we can allow more or less anything appropriate.

Link to comment
Share on other sites

On 1/30/2019 at 8:46 PM, Igor said:

 

Perhaps this can be solved rather with better oriented communication? Let's say we want raise awareness. Forum has some sort of ads system, which is not used. There, we could run rotating messages: 


# reporting a bug without logs will be ignored

# technical support is volunteer based

# if you care for our time and provide all necessary info ...

# make sure you open topic in a right place
+ more creative tweaked by @chwe :D

 

May you create a (hidden) testing forums for this feature, just to get a look'n'feel for it?

Link to comment
Share on other sites

55 minutes ago, Tido said:

@Igor, did you run an update, I think I miss information on users and the forum in general

 

because you did ask :)
since weeks I have to "mouseover" or click on User-Icons and "Like"-Numbers to see whats behind.
As I did remember right it was shown without that every time (like who did like or the User-Statistics).
I did like the statistics because then I know if I do answer to a beginner or a "pro" :)

Link to comment
Share on other sites

posting the tutorial might be worth.. doesn't seem to be an boardissue, rather an general debian/ubuntu issue..

 

@Igor can you rename 'Peer to peer technical support' or it's subtext so that we can move general linux questions also there? or hopefully others might get it that dev and tech support is likely the wrong place for it?

Link to comment
Share on other sites

22 hours ago, chwe said:

can you rename 'Peer to peer technical support' or it's subtext so that we can move general linux questions also there? or hopefully others might get it that dev and tech support is likely the wrong place for it?


Proposed actions:
 

1. Renaming section "Technical support" to "Bug tracker" (leave restrictions as is)

2. Merging "Common issues" with "Peer to peer" and place under "Community forums" section

3. Creating new section "First aid" 
    - move "SD card and power supply"
    - create "Board doesn't boot"    
    
    or move "SD card and power supply" one level up and rename to "Board doesn't boot"    

 

Alternatively:

4. Make "armbianmonitor -u" field mandatory for "Bug tracker" section except "board doesn't boot"

5. Move NXP and Armada A388/A3700 under "Other supported boards"

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines