How to: correctly use antiX forum

[Member PPC]

– Some users don’t value that they can have a completely free OS, that runs on almost any still functioning computer on this planet- please, always appreciate that- a lot of people worked hard, for free, so you can have it… The same goes for the forum, many good people voluntarily work here, providing a better “Costumer Service” than, well most paid Costumer Services…
– Assume that antiX works normally, even if in a different way from what you are used to or expect. If it does not work, for normal tasks, like opening a file or editing it, it’s a lot more probable that you are doing something wrong, than antiX has a bug (ex: a bug that does not, for example let you correctly open or edit a file…)
– Try to use general concepts while asking for help, while still giving details of what you are trying to do, what error you got, and what steps you took to try to solve that problem – For example “I can’t get back to my spaceship” is a nice start- then you should state how you tried to do (example: using the command “HAL, open the pod bay”, etc); Then state the error (Ex: The computer says “I’m sorry Dave, I can’t do that”, before proceeding to try to kill you); then state what steps you took to try to solve the problem (Ex: you tried to repeat the command, rephrase it, then finally, you jumped into the vacuum, without wearing the spacesuit helmet, and manually tried to open the pod bay).
This helps people that will try to help you here in forum- so you don’t get an advice to try to do something you already tried, saving everyone some time.
– Don’t treat the forum like it is your private Linux school, making endless, sometimes contradictory questions about how to do general things, that you can learn anywhere (ex: teach me use a File manager… Now teach me how to use the terminal) – there are lots of forum posts, wiki entries, YouTube videos, blogs, articles on the web for almost any single thing you may want to do, with the exception of some very antiX specific things that have never been addressed here in the forum, or, if they were, they are outdated… Use your brain, practice your skills, search for help on previous forum entries, the wiki, the help files, using search engines.
antiX is based in Debian, so most software/tips/how-tos that are related to Debian and are not dependent on systemd, the Desktop being used (ex: XFCE, KDE, Gnome) or a particular application that antiX does not include (Ex: a certain File Manager, or a certain Terminal Emulator), will work perfectly well for antiX… If all that fails, then ask for help here.
– Usually it’s nice to keep just one subject per thread, so people both trying to help or searching for help on a subject know exactly what they are getting into. A forum thread called “How to beat HAL at chess” should not include a question like “How to make HAL let me back in into the spaceship” – one subject can be solved, but not the other – if both are in the same thread, how will people know if one of them has a solution, other than parsing sometimes dozens of pages on the same thread?

P.

• This topic was modified 1 year ago by PPC.
• This topic was modified 1 year ago by PPC.
• This topic was modified 1 year ago by PPC.

[Member Noman01]

Helpful

Up

1

::

I like how you think.

[Moderator Brian Masinick]

Helpful

Up

1

::

Thanks for writing this @PPC: ! We have forum etiquette and forum policy topics, but this is something that has been missing, and you put it together nicely.

Perhaps when we receive a lot of stuff where these matters have not been followed, we can include this thread; our friend @MarceloCripe: already references a few of your other well-written topics. I suggest that this is another one to add to the “recommended reading list”. Much appreciated!

• This reply was modified 1 year ago by Brian Masinick.

--
Brian Masinick

[Member stevesr0]

Helpful

Up

0

::

Another part of “correct usage” of the forum is to post bugs that ARE bugs. Sometimes this has lead to the production of a fix.

Additionally (and of great value) are posts that describe howto do something (including how to solve a problem!)

I have found those posts very helpful.

Recently, a mechanism for adding a “helpful” point to a post was added. I have used that a few times.

It would be nice if (a) that was widely used and (b) if we could search by most helpful threads. (currently searching by “most popular” brings up the top fifteen threads by number of replies, while searching by the “most replies”, brings up the same top fifteen, followed by several thousand others, presumably in order of the number of replies.)

(Parenthetically, I recognize both Brian and PPC as contributing greatly to me as a forum participant. Thanks.)

stevesr0

[Member blur13]

Helpful

Up

1

::

Before posting your question try typing this in google:

site:antixforum.com your question here

maybe its already been solved. I find this to be more efficient than using the search function thats provided by the forum itself.

[Moderator Brian Masinick]

Helpful

Up

0

::

https://sqa.stackexchange.com/questions/27680/what-to-do-when-defect-is-found-in-production-but-not-during-the-qa-phase

This link presents some reasonable processes, and also identifies the fact that not all defects are found during the official and unofficial testing phases of projects.

The most important thing I know of when an issue is found that is thought to be a defect is to:
1) Describe each step performed that led to the behavior. Include things like – the kind of system being used, the things that were taking place when the problem was observed, the data, if any, that was used when the observed behavior occurred and so on. Anything useful in reproducing the steps is vital.
2) If a problem can’t be reproduced, it can’t be reliably fixed by a developer.

Here are some guidelines from that link above:
The process we follow where I work when a defect is reported in production might give you some perspective:

Reproduce the problem. If possible, we try to reproduce on production. Failing that, we’ll use the staging environment which is a mirror of production except when we have a new deployment staged there prior to release.

1) Analyze the problem. First we determine whether the problem is actually a defect. In a complex application it could be a misunderstanding or thinking that intended behavior isn’t what is supposed to happen.
2) How old is it?. If it is a defect, we investigate to determine how long that defect has been around. We’ve found that after major deployments our customers are much more sensitive to the application and can pick up issues that have been around for years as a result.
3) What is the impact?. It’s rare for us to accidentally let a show-stopper defect through, but it does happen.
4) Prioritize the problem. Prioritization generally takes into account how long it’s been in the system, how badly it impacts affected customers, and what proportion of the customer base it hits.
5) Determine the fix. Depending on the issue and how it’s prioritized, this can be a quick hack to make things work with a more comprehensive fix scheduled for later, or it can be a proper correction to the problem.
6) Schedule the fix. Again, what the schedule is depends on the nature of the problem. We have a very small team (4 developers and 1 tester supporting and enhancing multi-million LOC legacy applications and trying to build something more modern to replace them at the same time) so the demands on our time mean we can’t always put a fix in quickly.
7) Code, Test, & Deploy the fix.
8) Root cause analysis. Depending on the scheduling, this could come before step 8, but it generally doesn’t happen until we’ve at least prioritized the issue and communicated workarounds to the customers if any exist.

Depending on the severity of the issue, the whole process can be completed in under an hour, or it can be months before the defect is scheduled for a fix – or anything between those extremes.

Things we do and don’t do:

* We do not blame. If I feel that I should have caught a problem before release I will say so, but nobody blames anyone else.
* We do list contributing factors. These can and do include things like complexity of the code, lack of knowledge about how the application is used, unreasonable deadlines, and so forth. These are generally things that make it more likely that mistakes will happen rather than direct causes, because sometimes a problem gets through because of a perfect storm of contributing factors rather than a direct cause.*
* We try to add precautions to prevent this kind of problem recurring.

--
Brian Masinick

[Moderator Brian Masinick]

Helpful

Up

0

::

Another suggestion that we generally ask for as part of the question, answer, help dialogue is to get information about the hardware and software on the system.

A text listing of the output of either

inxi -Fxz
or
inxi -zv7

can often provide valuable information for understanding the configuration of the system under discussion.

--
Brian Masinick

[Member stevix]

Helpful

Up

5

::

I would like to add one further thing to this thread – Please, Please, let us know how you get on. I’ve seen it on a number of occasions where somebody asks a question, perhaps 3 or 4 people make suggestions, then the OP disappears. So we’re all left in the dark, not knowing which, if any of the suggested fixes worked. It’s not very polite either. Obviously this isn’t specific to antix, and no doubt applies to many forums.

[Moderator Brian Masinick]

Helpful

Up

0

::

stevix wrote:

I would like to add one further thing to this thread – Please, Please, let us know how you get on. I’ve seen it on a number of occasions where somebody asks a question, perhaps 3 or 4 people make suggestions, then the OP disappears. So we’re all left in the dark, not knowing which, if any of the suggested fixes worked. It’s not very polite either. Obviously this isn’t specific to antix, and no doubt applies to many forums.

Thank you; we DO want to know when things are solved; usually a moderator or administrator will update the title of the thread when a matter is solved — IF we are notified appropriately.

--
Brian Masinick

[Author]

Posts