Tức là người đó đã tìm hiểu về vấn đề đó rồi, nhưng vẫn chưa nắm chắc lắm cho nên đăng câu hỏi lên để mọi người có thể giúp đỡ để hiểu rõ hơn về vấn đề đó. 
, đôi lúc mình thấy việc đặt câu hỏi cũng là một điều cần phải học
Nên hay không việc trả lời các câu hỏi quá cơ bản?
3 Likes
đồng ý với bạn @Levis , trên quan điểm cá nhân đúng là chúng ta cần phải search google để tìm câu trả lời và ngay cả bản thân mình cũng như vậy đây là cách tốt nhất để chúng ta có những kỹ năng tìm kiếm trước khi đặt ra câu hỏi. Nhưng đứng trên tư cách là một thành viên của diễn đàn mình không quan tâm lắm việc câu hỏi này đơn giản như thế nào, và câu hỏi này đã có câu trả lời ở những trang web khác hay chưa. Mình chỉ quan tâm đến việc câu hỏi này chưa từng được đề cập trên diễn đàn DNH, và mình cũng chỉ muốn trả lời thẳng vào những câu hỏi như vậy hoặc là gợi ý link tham khảo để giúp đỡ họ và hơn nữa nó không có vi phạm nội quy của diễn đàn DNH vì câu hỏi này chưa từng có trước đây. chuyện này chắc phải nhờ @ltd kiểm tra lại. Vì theo như quy định diễn đàn chưa hề có quy định cấm user đặt những câu hỏi quá cơ bản và hơn nữa là câu hỏi này chưa được hỏi bởi bất kỳ bởi một người nào khác trên diễn đàn. Tóm lại bạn ấy đặt câu hỏi này là hợp lệ và chẳng ai có quyền close topic này và mình dám chắc với bạn trên diễn đàn DNH này có hàng tá câu hỏi thuộc loại cơ bản những vẫn không bị close topic thì tại sao một câu hỏi như vậy là bị close một cách vô lý. Vì sau này chắc chắn những người khác cũng sẽ cần search một nội dung tương tự như vậy và DNH sẽ cho họ câu trả lời đó. Mình sẽ dừng comment về việc tranh luận tại đây.
5 Likes
Mình cùng quan điểm với @khiemnvd, bạn đó post bài hỏi với mục đích tìm được lời giải đáp.
Theo qui định của diễn đàn thì không có bất cứ điều khoản nào bạn đó vi phạm vậy tại sao close topic?
Diễn đàn là open, các bạn đọc có thể thấy chuối thì bỏ qua, ai có kinh nhiệm và nhiệt tình thì trả lời.
1 Like
@khiemnvd câu hỏi tạm thời close để thảo luận bên này, nếu để câu hỏi đó open sẽ gây tranh cãi.
@thanhmssl10 câu trả lời của em có thể được dùng làm câu trả lời cho câu hỏi JSON, chỉ là thành viên của chúng ta chưa thể chất lượng bằng thành viên SO.
Đồng tình, nếu giúp được thì giúp cho trót, không thì lơ hehe
Riêng topic này rất hay, Đạt muốn xem mọi người thảo luận về cách hoạt động của chúng ta. Đạt muốn xây dựng một nơi thảo luận chất lượng hơn, điều đó là phụ thuộc vào các thành viên có kinh nghiệm.
3 Likes
Giữ nguyên tắc: “Tranh luận để đi đến sự thống nhất, không dẫn đến sự chia rẽ nhé.”
2 Likes
Bạn quá áp đặt, theo mình thì đây không phải là một môi trường “lập trình viên đam mê” only. và cũng không phải ai cũng sẽ làm như bạn nói. Mỗi người có 1 cách học khác nhau, hãy nhìn vào kết quả họ học được chứ không phải chê bai cách họ làm thê nào.
1 Like
Với việc học thụ động thế này theo bạn kết quả như thế nào , mình cũng từng phỏng vấn nhiều bạn sinh viên mới ra , họ rất thụ động không thể suy nghĩ đưa ra cách giai quyết các vấn đề , vậy tại sao khi học chúng ta không loại bỏ thói quen đó đi . Mà thôi đó suy nghĩ mỗi người nên thôi mình dừng tại đây.
Mọi người đóng góp ý kiến mang tính xây dựng, đừng bực bội không cần thiết nhé 
Mục đích là chúng ta có một cộng đồng vui vẻ, học hỏi lẫn nhau.
2 Likes
Em thấy anh @ltd nên chỉnh thêm chức năng: Hiện bảng hướng dẫn ngay khi login dành cho người mới đăng kí (VD như: Trước khi hỏi, hãy tìm kiếm,… và Hãy ghi đầy đủ tiếng Việt có dấu để mọi người hiểu vấn đề của bạn và giúp đỡ…chẳng hạn). Tại thực sự thì nhiều bạn khi check mail chỉ để kích hoạt thôi, còn cái inbox với cái mail sau đó thì ít quan tâm (như em hồi bé 
) nên ta “quẳng ngay trước mặt” chỉ cho họ thêm lần nữa 
Còn việc câu hỏi quá cơ bản? Em thấy tùy người, nếu mình có lòng hảo tâm thì giúp, nhưng cần phải xác định giúp như thế nào? Nếu muốn hỏi 1 khái niệm, em nghĩ nên hướng cho họ: Tìm kiếm (Google, Wiki, DNH) => Xem khái niệm đó => trong cái đoạn Định nghĩa đó, nếu có từ nào mơ hồ thì mình đăng đoạn đó lên và bôi đậm từ không hiểu. Ngược lại, nếu thấy chắc rồi họ cũng tự google thôi thì mình cứ bơ, việc mình reply “Tự google đi bạn” “Mấy cái này dễ ợt cũng hỏi” thì [spoiler] mình còn rãnh hơn cái người hỏi nữa [/spoiler] , nếu đã xác định reply thì nên làm một cái reply chất lượng, lịch sự, hướng cách giải quyết hoặc giúp chủ topic giải quyết thay vì một reply gây mất lòng nhau.
Sẵn tiện em thấy dạo này DNH phát triển khá đa dạng như lấn sân sang các lĩnh vực như Mua sắm, tư vấn tuyển sinh, hướng nghiệp, thời sự, chuyên mục “Bạn và tôi”…
P/s: Sao trên điện thoại không có nút biểu tượng cảm xúc vậy anh Đạt 
1 Like
Nếu có thêm một chức năng làm quiz trước khi đăng bài thì tốt anh nhỉ…
Sẽ có thêm một trust level nữa là Nice topic và Old member.
Old member:
- Những member tạo tài khoản được nhiều hơn 30 ngày và có nhiều hơn 50 điểm post bài (1 bài post được tính 10 điểm, mỗi trả lời được tính 1 điểm) sẽ nhận được Old member.
- Old member mới có quyền like các bài post của các thành viên khác.
Nice topic:
-
Những thành viên có hơn 5 bài post được hơn 5 like mỗi bài. (Theo sự theo dõi của em thì tình hình diễn đàn việc có 5 like cho một câu hỏi cũng khá khó nên cần cân đối lại con số này.)
-
Nếu không đạt được Nice topic thì mỗi khi thành viên đó đăng bài sẽ phải thực hiện làm một quiz bao gồm bốn câu hỏi sau:
-
Bài viết trên có trùng với bài viết nào trong diễn đàn không?
-
Tiêu đề bài viết có khái quát được nội dung không?
-
Trong bài viết có đưa ra phương án cũng như nỗ lực tìm kiếm câu trả lời của bản thân hay không?
-
Nội dung bài viết có dễ hiểu hay không?
=> Hạn chế spam và mọi người cũng có trách nhiệm hơn khi viết bài. Người mới sẽ quen với 4 câu hỏi trên còn người cũ thì không bị mấy câu hỏi đó làm phiền.
Nếu như bài viết không vi phạm 4 câu hỏi trên thì người trả lời không có quyền phản ứng gay gắt với người đặt câu hỏi về cách đặt câu hỏi.
P/s: Đây không phải là ý tưởng của em mà là phương thức hoạt động của stackoverflow. Chỉ khác là thay vì hỏi thì nó sẽ hiện ra cái này. Tuy nhiên em nghĩ là hỏi sẽ trách nhiệm hơn vì người dùng sẽ có những action cụ thể thay vì bỏ qua nội dung bài viết:
How do I ask a good question?
We’d love to help you. To improve your chances of getting an answer, here are some tips:
Search, and research
…and keep track of what you find. Even if you don’t find a useful answer elsewhere on the site, including links to related questions that haven’t helped can help others in understanding how your question is different from the rest.
Write a title that summarizes the specific problem
The title is the first thing potential answerers will see, and if your title isn’t interesting, they won’t read the rest. So make it count:
Pretend you’re talking to a busy colleague and have to sum up your entire question in one sentence: what details can you include that will help someone identify and solve your problem? Include any error messages, key APIs, or unusual circumstances that make your question different from similar questions already on the site.
Spelling, grammar and punctuation are important! Remember, this is the first part of your question others will see - you want to make a good impression. If you’re not comfortable writing in English, ask a friend to proof-read it for you.
If you’re having trouble summarizing the problem, write the title last - sometimes writing the rest of the question first can make it easier to describe the problem.
Examples:
Bad: C# Math Confusion
Good: Why does using float instead of int give me different results when all of my inputs are integers?
Bad: [php] session doubt
Good: How can I redirect users to different pages based on session data in PHP?
Bad: android if else problems
Good: Why does str == “value” evaluate to false when str is set to “value”?
Introduce the problem before you post any code
In the body of your question, start by expanding on the summary you put in the title. Explain how you encountered the problem you’re trying to solve, and any difficulties that have prevented you from solving it yourself. The first paragraph in your question is the second thing most readers will see, so make it as engaging and informative as possible.
Help others reproduce the problem
Not all questions benefit from including code. But if your problem is with code you’ve written, you should include some. But don’t just copy in your entire program! Not only is this likely to get you in trouble if you’re posting your employer’s code, it likely includes a lot of irrelevant details that readers will need to ignore when trying to reproduce the problem. Here are some guidelines:
Include just enough code to allow others to reproduce the problem. For help with this, read How to create a Minimal, Complete, and Verifiable example.
If it is possible to create a live example of the problem that you can link to (for example, on http://sqlfiddle.com/ or http://jsbin.com/) then do so - but also include the code in your question itself. Not everyone can access external sites, and the links may break over time.
Include all relevant tags
Try to include a tag for the language, library, and specific API your question relates to. If you start typing in the tags field, the system will suggest tags that match what you’ve typed - be sure and read the descriptions given for them to make sure they’re relevant to the question you’re asking! See also: What are tags, and how should I use them?
Proof-read before posting!
Now that you’re ready to ask your question, take a deep breath and read through it from start to finish. Pretend you’re seeing it for the first time: does it make sense? Try reproducing the problem yourself, in a fresh environment and make sure you can do so using only the information included in your question. Add any details you missed and read through it again. Now is a good time to make sure that your title still describes the problem!
Post the question and respond to feedback
After you post, leave the question open in your browser for a bit, and see if anyone comments. If you missed an obvious piece of information, be ready to respond by editing your question to include it. If someone posts an answer, be ready to try it out and provide feedback!
Look for help asking for help
In spite of all your efforts, you may find your questions poorly-received. Don’t despair! Learning to ask a good question is a worthy pursuit, and not one you’ll master overnight. Here are some additional resources that you may find useful:
Writing the perfect question
How do I ask and answer homework questions?
How to debug small programs
Meta discussions on asking questions
How to ask questions the smart way — long but good advice.
1 Like
Nhưng thông tin này có hiển thị trong 2 post đầu tiên của members, nhưng tiếc là họ không đọc
Đạt cũng có tham khảo cái này, rất muốn thực hiện nhưng SO bản chất cũng là do thành viên họ flag hoặc downvote hoặc sửa câu hỏi nên mình không thấy câu hỏi dở đấy.
flag và downvote nhiều thì thành viên sẽ hiểu. Theo Đạt là thế, vì theo Đạt thấy thì ít người chịu làm theo hướng dẫn lắm. Họ chỉ nhớ khi bị downvoted.
3 Likes
Mình ít khi từ chối câu hỏi khi mà mình chắc chắn có thời gian và kiến thức để trả lời câu hỏi đó. Thời gian qua mình cũng bận nên ít tham gia DNH. Thỉnh thoảng lên cũng bắt gặp nhiều câu hỏi đơn giản. Nhưng không vì thế mà khó chịu người hỏi, bởi đôi khi chính mình phải học lại kiến thức khi gặp câu hỏi đó. VD: hoán vị 2 số nhưng không dùng biến tạm?
Nhân đây là một câu hỏi hay, mình xin phép chia sẻ ít dòng.
Vấn đề chúng ta nên suy nghĩ ở đây là thái độ, từ cả 2 phía
Về phía người hỏi (A)
A hỏi nhưng chưa chuẩn bị tâm thế, kiến thức cho câu hỏi. Cứ như bất chợt hỏi, nhưng không tìm hiểu trước đó.
A nhận được câu trả lời nhưng không bao giờ thỏa mãn. Vì sao, vì A không tìm hiểu, không làm theo, A mong chờ ai đó làm sẵn cho từ a-z.
A rất dễ tự ái khi nhận được câu trả lời dạng như hãy google đi, câu này dễ, hãy suy nghĩ đi. Mình nghĩ tự ái là không nên? Hãy thử làm theo xem sao.
A là người biết tuốt, A hỏi, nhưng sẵn sàng phản biện lại gay gắt bất cứ câu trả lời nào, cứ như A là đúng nhất. Nếu vậy tại sao còn hỏi, hãy action đi.
A chưa đủ tầm kiến thức so với câu hỏi, chỉ là nghe ai đó nói nó hay hay nên hỏi: VD: làm ứng dụng chat bằng Node js như thế nào, trong khi còn chưa có khái niệm về node.js là gì, real-time là gì…
… và nhiều thứ nữa… mong rằng A sẽ không tự ái vì chia sẻ của mình.
Còn phía người trả lời thì sao? (B)
B rất thích câu hỏi khó, đòi hỏi sự tư duy, vì đơn giản là ai cũng muốn học hỏi kiến thức mới. Vì thế B thấy khó chịu khi bắt gặp câu hỏi đơn giản quá. Nếu là B, B sẽ tự tìm hiểu trước.
B thấy mệt mỏi vì giải thích hoài mà A không action, không chịu hiểu (hoặc không hiểu), theo mình B hãy kiên nhẫn, tìm hiểu xem vì sao mình nói hoài mà A không hiểu. Do mình nói quá dở thôi, đừng đổ lỗi cho người khác.
B sẽ rất ức chế nếu gặp A biết tuốt, vì suy nghĩ, mình giúp nó mà cứ như nó là thầy mình. Nếu B ở trường hợp này hãy cứ cư xử tinh tế và vui vẻ nhé.
B tự phụ, kiểu B này luôn cho mình ở vị trí rất cao, câu khó quá không biết trả lời thì thôi, nhưng câu dễ thì sẽ nhảy vào trả lời kiểu khinh thường, câu này dễ ợt, làm tí là xong. => A tự ái là đúng thôi.
Có nhiều khi B gặp cùng câu hỏi ở nhiều nơi, và trở nên ngán ngẩm, vì B là người nhiệt tình nên gặp nhiều thôi (bản thân mình từng gặp 5 câu hỏi trong 1 ngày, cùng một nội dung, ở 5 nơi khác nhau) tất nhiên mình chọn cách trả lời lịch sự, vì 5 người kia ở 5 môi trường khác nhau.
…
Và sau cùng, có lẽ ý kiến này sẽ nhận nhiều gạch đá, nhưng không sao cả, vì tinh thần chung, chúc tất cả các bạn đều tìm thấy niềm vui & tri thức khi tham gia DNH.
8 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?