SgDotNet
Singapore Professional .NET User Group -For Cool Developers

Rules and Guidelines

Latest post 04-14-2005 4:39 PM by icelava. 3 replies.
  • 09-24-2004 9:35 PM

    Rules and Guidelines

    Locked |Contact

    The following post items are a couple of rules and guidelines we hope all members and users of this Forums will observe. Remember, adhere to the rules and follow the guidelines.

    Enjoy your stay and the company of the community.

    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

  • 09-24-2004 9:36 PM In reply to

    Forums rules

    Locked |Contact
    1. Be civil
    Members are expected to exhibit mature attitude and professional behaviour. Argument and debate is welcome, but with composure. Childish quarrelling and bickering will not be tolerated. No cursing, swearing, name-calling. No groupism (racist, sexist, technologist, etc) slurs and provocation. No disruptive interjection of posts blatantly irrelevant to thread topics.

    The SgDotNet management reserves the right to edit/delete posts, suspend/permanently ban any member who acts in such manner to disrupt and sour the community experience of other Forums users.

    2. No academic solicitation
    Students are not allowed use the Forums to "outsource" their academic assignments, tutorials, projects, and such works. Meaning, you (students) cannot engage experienced and professional individuals to complete the your homework.

    Yes, it's trendy in the industry right now, but that applies at the business level. They have the purposes of getting you to exercise the subjects and skills taught to gain a practical working experience. We do not agree to have you rob yourself of the very core skillsets your future career depends on. If you seek to become a chef, do you ship the ingredients out of the restaurant for somebody else to cook the dishes?

    3. Advertising
    Advertising shall only happen under the Products & Services forum. Advertisements must be about relevant products and services focused on making development teams for effective and efficient in their work.

    4. No brusque demand for help
    Peer-to-peer community support is not to be perceived as paid vendor technical support. Those who help choose to do it out their own free time, so you cannot imply (and enforce) your time is more important than theirs. Ask courteously and comprehensively. Politely reject those who offer a wrong solution, stating why theirs won't work. Remember who is the one lacking knowledge and in need of help.

    5. Keep noise in technical forums at a minimum.
    You may be friends with another member and drop in insider jokes but remember others are not. Not encouraging people to remain unfriendly strangers forever, but keep in mind others come to read the technical content of your discussions and such "contamination" are quickly perceived as noise in the thread and ultimately lowers the quality of the content.

    One super major reason why Charles Carroll's AspFriends.com mailing lists were so successful was due to his anal (yes) moderation to keep discussions on-topic and to prevent people from turning the lists into noisy canteens. That has the detrimental effect of driving experts and gurus away and unsubscribing from the lists. High quality discussions keep things interesting for other members to continue participating.

    Therefore, discouragement to "oh I see...", "thanks", "i'll try that" posts. Yes, we mean that. Those mean nothing and add no value to the discussion. We do not mean to be an ingrate, but instead, post back technical information to conclude the discussion:

    "I see, so by adding a handler the PreRender event, I can effectively alter the contents after of the DataList for that final tweak before the HTML is churned out. I tried your suggestion and it works beautifully, thanks!"

    "Thanks but I tried your suggestion to alter the content on PreRender but the old data as on ItemDataBound is the same as before. Below is the new code.... "

    Do not post just to say "i have that problem too. Any solution?". That adds no value - imagine common problems with 200 "me too" posts.

    Short personal gratitude with no technical content should be delivered via email or private message. Also, do not privately solicit the help of others unless they have explicitly expressed that channel is open - you place an emotional handcuff on individuals to help you out if they never welcome it. Besides, private help will be missed by the public who may very well benefit from the discussion and possible conclusions.

    6. Write in good, proper English.
    This is a forums board for professionals. Please do not try to bring in your 1337$p34k and abbreviations and think you are cool. It is not cool; whole paragraphs of such text only makes it difficult for others to read and "translate" your points and message, thereby ensuring a great majority in losing interest in your post. This is direct evidence to your ability to communicate and articulate yourself properly and clearly, and by extension, your credibility.

    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Filed under:
  • 09-24-2004 9:37 PM In reply to

    Troubleshoot and Asking Help guidelines

    Locked |Contact
    My original intention was to write a summary condensed from the following comprehensive papers and articles on how to ask effective questions on the Internet (in fact, in life).
    http://www.adopenstatic.com/personal/help.asp
    http://www.catb.org/~esr/faqs/smart-questions.html
    http://www.ultratech-llc.com/Personal/Files/?File=~help.TXT

    However as I wrote on, I figured I should include in this material how I perform troubleshooting to solve my own problems before even enlisting the direct help and knowledge of others, for this is something I unfortunately find sorely lacking in the operating processes of an unhealthy number of people (first hand). But still, those documents are worth your while to read.

    Those who actively watch anime (Japanese cartoon animation) may know of a late 2002 TV series called Spiral: Bond of Inference. The protagonist is a highly intelligent school boy, Narumi Ayumu, who exhibits deduction skills that will put professional detectives to shame. While it had a very disappointing and lackluster second half, the first half was a truly amazing and engaging Cluedo experience as you watch Ayumu perceive clues and details involved a case in a very logical manner to derive answers and solutions to problems. His favourite statement, a principle that rings so strongly and true with me because that's how I work, thus deserving space in my signature:

    The melody of logic will always play out the truth

    But I digress. Here are the guidelines you can use to approach problems on a troubleshooting spin. Remember the keyword is "inference", not "conjecture".

    1. Know what you're trying to achieve in the first place
    If you don't know where you want to go, it's pretty hard to plot a route to drive there, or ask people for directions. Only with a definitive destination in mind can you make concrete plans to reach there. It must be clear in mind. "I want the pages to work." is too vague. How do you want them to work? Know the difference between a goal and an objective, and divide your work into objectives. "I want the page to render parent records in the left DataGrid, and child records in the right one." is a much more concrete concern.

    2. Know why you're trying to achieve the above
    Because in the process of discovery, others are likely to find certain implementation flaws in your method and suggest something that works better in their experience. That may or may not benefit you to take it up, as your background policies and motivations could be a potential blockade (e.g. company security policy). Have your reasons at hand to assess compatibility and potential to implementing new ideas.

    3. Know what you're using to achieve the above
    As in, the OS, the application platform, software versions, language, architecture, IDE etc. Yes, all these may sound obvious but quite frequently people have no idea. Find out as much of the layers and tiers you sit on as possible, so you can picture the environment your application runs on.

    4. List your attempt/approach in steps
    Lay out step by step the action items you took in attempt to accomplish the task. Each should be a logical, fluid flow of instructions taught from valid well-known documentation, or at least something you derived from your own research - Have a clear reason why you are carrying out each step in the first place.

    5. Note down the behaviour/result/error
    Best copy and paste these verbatim, or write down the phenomenon in detailed description, because you are going to forget about it 5 minutes later. Something recorded down in medium won't be lost unless burnt away. Analyse the message or behaviour and write down what you think of the matter, and why you think this is happening. Call upon your previous experience to infer causes and influences.

    6. Isolate
    With the observed occurrence, determine the "epicenter". Figure which components can be reponsibile for such a behaviour/error, and thus constantly narrow down, narrow down, narrow down, until you have isolated the faulty portion.

    e.g. "Server not found" certainly doesn't sound like your SQL statement was written wrongly. If it's code, debug and step trace to find the point where the exception is thrown.

    7. Try alternatives
    Tweak the parameters and variables (not necessarily literally a programming language) to the scenario and observe the results. Repeat with Step 5-6 as necessary. Always record.

    8. Make these your best friends
    http://google.com
    http://groups.google.com
    http://msdn.microsoft.com
    http://support.microsoft.com
    http://technet.microsoft.com

    Not a satistical fact, but I can say a third to half the solutions I give others have been mere searches with keywords from the very content of the requestor's plea. Know that whatever problem you face, the odds are it's been encountered and solved before. groups.google.com is especially useful in digging out past discussions on the same matter and their possible solutions or workarounds. Note down, again, what you read of the discussions and infer further with whatever new information has been disclosed.

    9. Prepare a proof-of-concept if possible
    Whenever possible, especially in code, identity the possible components contributing to the phenomenon and build a new program that does nothing other than to recreate the problem. This will further solidify the issue that you have correctly isolated the source of the problem/error.

    10. Seek human help
    So all that didn't help, it's time to approach real people now. Correct, this step is so indeed so far down. Why so? Because you cannot rely on and expect others to perform these very steps for you. That is just what others have to do to solve your problem. The first thing then is to find the appropriate forum/mailing list to post to. Well, moderators will move irrelevant threads, but knowing the subject matter yourself is very useful in finding appropriate help quicker.

    Prepare a descriptive subject title to summarise the nature of your problem to others. "Please help" or "Urgent" doesn't magically prioritise your case as more important than others' - everybody needs help. In fact, that is more likely to have less people view your post as some experts only visit posts by topics that interest them. So describe your problem well.

    11. Complete your post, entirely
    Remember my advice to note down, write down everything in the earlier steps? That is not only for you to remember, but for you to unload in the post you explain clearly and fully to others to grasp the situation you're in. Plain a clear picture to them, and you get more accurate answers. "My pages are not working. Why so?" won't get you far. Imagine these scenarios

    "Doctor, I'm feeling unwell. Cure me."

    "Mechanic, my car's spoilt. Can it be repaired?"

    "Police, there's a robbery. Arrest them."

    I will lay down money each of the above will have the respective professional coming back to you with questions asking you why/how you even came to those conclusions in the first place. Be descriptive, very descriptive, if you want people to help you. Help others to help you.

    Caution: Do not, however, paste your 1000-line class code and expect others to perform full-fledge code reviews for you. Post only relevant code blocks. Do explain the architecture/design as necessary, though.

    12. Format well
    Properly format and break down your information into logical paragraphs - a single paragraph is like one huge long breath of continuous speech. NO ALL CAPS EITHER - IF YOU DIDN'T KNOW, THAT IS THE TEXT EQUIVALENT OF SHOUTING. When quoting others, don't post wholesale - we already know what s/he said in the previous post. Trim down to the relevant points/statements, so they provide better context. Don't make others work to read your content.

    13. State your thoughts on the matter
    Tell others what you think and what your inferred from it. Please don't expect others to think on your behalf. You are likely not parting with your salary for them. Think with them, and contemplate their suggestions/ideas. It is also a good idea to state your experience and knowledge level, so others can adjust their level of communication according to your needs.

    14. Return to inform what works and what doesn't
    Leaving after getting a workable solution is very inconsiderate - that makes the discussion inconclusive. Remember others will meet the same problem and your report on what was the solution will be valuable.

    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

  • 04-14-2005 4:39 PM In reply to

    Responsibility is not transferable

    Locked |Contact
    To add a further level of disclaimer, please do recognise that information communicated in this forum does not liberate you of your responsibility and job of ensuring the solutions you apply are of sound and stable conditions. Therefore you cannot transfer the blame of any failure, loss, damage, injury, etc resulting from a suggestion/idea obtained from the discussions within this community.

    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Filed under:
Page 1 of 1 (4 items) | RSS
Copyright SgDotNet 2004-2008
Powered by Community Server (Commercial Edition), by Telligent Systems