ស្វែងយល់អំពី Community Reviews នៅក្នុង Symfony3

• sreypao


• 24 Mar 2017

Symfony គឺជា project open-source ដែលមាន សមាគមដ៏ធំ។ ប្រសិនបើអ្នកគិតថាអ្នកមិនទាន់ត្រៀមខ្លួនរួចរាល់សម្រាប់ការ ចូលរួមចំណែកនូវកូដ រឺក៏ ផ្នែកណាមួយ រឺ ការដោះស្រាយនូវបញ្ហា និងទាញយកការស្នើ (PRs) អ្នកអាចចាប់ផ្ដើមជាការធ្វើខ្លួនពាក់ព័ន្ធនិងអោយមកវិញនូវគំនិតមួយចំនួនបានផងដែរ។ ជាការពិតណាស់ បើអ្នកធ្វើដូចនេះបាន អ្នកនឹងជោគជ័យជាមួយនឹង Symfony ផងដែរ។

១) ហេតុអ្វីបានជាការពិនិត្យឡើងវិញមានសារៈសំខាន់?

Community reviews មានសារៈសំខាន់សម្រាប់ការអភិវឌ្ឍនូវ Symfony framework ចាប់តាំងពីមានការស្នើជាច្រើននិងកំណត់ហេតុនៃ bug មានចំនួនច្រើនជាងសមាជិកក្នុង ក្រុមស្នូលនៃ Symfony ដែលជាអ្នកធ្វើការពិនិត្យនិងជួសជុល ព្រមទាំងបញ្ចូល ផងដែរ។

នៅលើ Symfony issue tracker អ្នកអាចស្វែងរកធាតុជាច្រើនបានផងដែរនៅក្នុង Need Review status៖

ទី១៖ Bug Reports វាត្រូវការពិនិត្យដើម្បីរកភាពពេញលេញ។

ទី២៖ Pull Requests ផ្ទុកនូវកូដដែលជួសជុលនូវ bug រឺក៏ implements នូវមុខងារថ្មី។ ការពិនិត្យនៃ ការស្នើដើម្បីប្រាកដថាពួកគេបានធ្វើការ implement បានយ៉ាងត្រឹមត្រូវ និងគ្របដណ្ដប់ទៅដោយ test case និងមិនណែនាំនូវកំហុសថ្មីៗ និងរក្សាបាននូវ ភាពត្រលប់ក្រោយ។

ត្រូវចាំថា អ្នកណាដែលមានការយល់ដឹងអំពីមូលដ្ឋានគ្រឹះមួយចំនួនរបស់ Symfony និង PHP អាចពិនិត្យមើលរបាយការណ៏នៃកំហុសនិងទាញនូវសំណើនោះ។ អ្នកមិនចាំបាច់មានភាពជំនាញក្នុងការធ្វើវាឡើយ។

២) Constructive

មុននឹងចាប់ផ្ដើម អ្នកត្រូវចាំថា អ្នកកំពុងរកមើលនូវលទ្ធផលនៃអ្នកផ្សេងទៀតដែលខំប្រឹងធ្វើយ៉ាងខ្លាំង។ ជាអ្នកធ្វើការពិនិត្យល្អត្រូវនឹកដល់ការរួមចំណែកធ្វើការរបស់ពួកគេ កំណត់នូវអ្វីដែលបានបញ្ចប់បានដោយល្អ កំណត់នូវអ្វីដែលគួរតែពង្រឹងបន្ថែមនិងស្នើរនូវអ្វីទៅមុខទៀត។

៣) បង្កើតគណនី GitHub

Symfony ប្រើនូវ GitHub ដើម្បីគ្រប់គ្រងនូវរបាយការណ៏នៃកំហុសនិងទាញយកសំណើ។ ប្រសិនបើអ្នកត្រូវការធ្វើការពិនិត្យ អ្នកត្រូវបង្កើតនូវគណនី GitHub និង log in។

៤) របាយការណ៏នៃកំហុសនៃការពិនិត្យនូវដំណើរការ

វិធីល្អដែលអាចចាប់ផ្ដើមជាមួយនឹងការពិនិត្យគឺ យករបាយការណ៏នៃកំហុសពី bug report នៅក្នុងការពិនិត្យ។

ដំណាក់កាលនៃការពិនិត្យ៖

ទី១៖ តើរបាយការណ៏រួចរាល់រឺនៅ?

របាយការណ៏នៃកំហុសដែលល្អផ្ទុកនូវ តំណភ្ជាប់ទៅកាន់ Symfony Standard Edition ដែលធ្វើការផលិតម្ដងទៀតនូវកំហុស។ ប្រសិនបើវាមិនមែនទេ នោះ របាយការណ៏គួរតែយ៉ាងហោចណាស់ផ្ទុកនូវ ព័ត៌មានដ៏ពេញលេញនិងឧទាហរណ៏នៃកូដដើម្បីបង្កើតនូវកំហុសម្ដងទៀត។

ទី២៖ ការបង្កើតកំហុសម្ដងទៀត

ដោនឡូដនូវ reproduction project និងតេស្តនូវកន្លែងណាដែលកំហុសអាចនឹងកើតមានឡើងម្ដងទៀតនៅលើប្រព័ន្ធរបស់អ្នក។ ប្រសិនបើអ្នករាយការណ៏ មិនផ្ដល់នូវ reproduction project សូមបង្កើតវាមួយដោយធ្វើការ fork នូវ Symfony Standard Edition។

ទី៣៖ Update Issue Status

ចុងក្រោយ សូមធ្វើការបន្ថែមការអធិប្បាយនូវ របាយការណ៏នៃកំហុស។ ត្រូវអរគុណទៅដល់អ្នករាយការណ៏សម្រាប់ការធ្វើរបាយការណ៏នៃកំហុស។ បញ្ចូលនូវ Status: <status> ទៅក្នុងការអធិប្បាយរបស់អ្នកដើម្បីបង្កអោយមាន Carson Bot របស់យើងដែលជាអ្នក Update នូវ status នៃបញ្ហា។ អ្នកអាចកំណត់នូវ status ទៅកាន់មួយក្នុងចំណោមខាងក្រោម៖

ក) Need Work ប្រសិនបើកំហុសមិនបានផ្ទុកនូវព័ត៌មានគ្រប់គ្រាន់ដើម្បីបង្កើតម្ដងទៀតទេ ត្រូវធ្វើការពន្យល់នូវព័ត៌មានដែលខកខាននិងយករបាយការណ៏ទៅកាន់ status នេះ។

ខ) Works for me ប្រសិនបើកំហុសមិនបានផ្ទុកនូវព័ត៌មានគ្រប់គ្រាន់ដើម្បីបង្កើតម្ដងទៀតទេប៉ុន្តែ ការងារនៅលើប្រព័ន្ធរបស់អ្នក រឺក៏ប្រសិនបើកំហុសគឺជា feature និងមិនមែនជាកំហុស ត្រូវផ្ដល់នូវការពន្យល់ដ៏ខ្លីនិងយករបាយការណ៏ទៅកាន់ status នេះ។

គ) Reviewed ប្រសិនបើអ្នកអាចបង្កើតកំហុសម្ដងទៀត ត្រូវធ្វើការយកនូវ របាយការណ៏ទៅកាន់ status នេះ។ ប្រសិនបើអ្នកបានបង្កើតនូវ reproduction project សូមបញ្ចូលនូវតំណភ្ជាប់ទៅកាន់ project ក្នុង comment របស់អ្នក។

ឧទាហរណ៏៖ ខាងក្រោមនេះជា comment សាមញ្ញមួយសម្រាប់ របាយការណ៏នៃកំហុសដែលគួរតែបង្កើតម្ដងទៀត៖

៥) ទាញយកសំណើរនៃការពិនិត្យមើលនូវដំណើរការ

ដំណើរការសម្រាប់ការពិនិត្យនូវការទាញយកសំណើ (PRs) គឺស្រដៀងទៅនឹងផ្នែកមួយនៃរបាយការណ៏នៃកំហុស។ ពិនិត្យឡើងវិញនូវការទាញនូវសំណើជាធម្មតាគឺចំណាយពេលយូរបន្តិចចាប់តាំងពីពេលដែលអ្នកត្រូវយល់អំពីមុខងារដែលបានជួសជុលរឺក៏បានបន្ថែមនិងស្វែងរកនូវការ implement គឺត្រូវបានបញ្ចប់។

វាជាការល្អក្នុងការពិនិត្យឡើងវិញជាផ្នែក ប្រសិបើអ្នកធ្វើការពិនិត្យឡើងវិញជាផ្នែកសូមធ្វើការអធិប្បាយពីការដែលអ្នកទទួលបាននិងចាកចេញពី PR ក្នុង “Needs Review” state។

ជ្រើសយកសំណើមួយពី PRs ពីក្នុងអ្វីដែលត្រូវការនៃការពិនិត្យឡើងវិញ និងអនុវត្តតាមដំណាក់កាលខាងក្រោម៖

ដំណាក់កាលទី១៖ តើ PR បានបញ្ចប់ហើយរឺនៅ?

រាល់ការទាញយកសំណើត្រូវតែផ្ទុកនូវ header ដែលអោយនូវមូលដ្ឋាននៃព័ត៌មានមួយចំនួនអំពី PR។ អ្នកអាចរកនូវទម្រង់សម្រាប់ header ក្នុង Contribution Guidelines។

ដំណាក់កាលទី២៖ តើមូលដ្ឋាននៃ Branch ត្រឹមត្រូវរឺទេ?

GitHub បង្ហាញនូវ branch ដែល PR ស្ថិតនៅខាងក្រោមនៃចំណងជើងនៃការទាញយកសំណើ។ តើ branch ត្រឹមត្រូវរឺទេ?

• កំហុសត្រូវតែត្រូវបានជួសជុលមុនគេបង្អស់ ជំនាន់នៃការថែទាំដែលផ្ទុកនូវកំហុស។ ពិនិត្យមើល Symfony’s Release Schedule ដើម្បីស្វែងរកនូវ ជំនាន់ចាស់ជាងគេដែលអាច support បាន។
• Features ថ្មីគួរ តែងតែបន្ថែមនូវ ជំនាន់នៃអភិវឌ្ឍថ្មី។ ពិនិត្យទៅលើ Symfony Roadmap ដើម្បីស្វែងរកជំនាន់ថ្មីដែលកំពុងអភិវឌ្ឍ។

ដំណាក់កាលទី៣៖ បង្កើតបញ្ហាម្ដងទៀត

អានទៅលើបញ្ហាដែលទាញយកសំណើគឺសន្មតថាត្រូវជួសជុល។ បង្កើតបញ្ហាម្ដងទៀតនៅលើ Symfony Standard Edition project និងព្យាយាមយល់ថាហេតុអ្វីបានជាវាមានហើយ។ ប្រសិនបើមានបញ្ហាភ្ជាប់ដែលមានផ្ទុកនូវ project រឺការតម្លើងវានិងដំណើរការវានៅលើប្រព័ន្ធ។

ដំណាក់កាលទី៤៖ ពិនិត្យកូដឡើងវិញ

ពិនិត្យកូដនៃការទាញយកសំណើនិងពិនិត្យវាម្ដងទៀតអំពីការវិនិច្ឆ័យមួយចំនួន៖

ទី១៖ តើអាស័យដ្ឋាននៃកូដ បញ្ហានៃ PR មានគោលបំណងជួសជុល រឺអនុវត្ត?

ទី២៖ តើ PR ស្ថិតក្នុងដែនកំណត់ទៅកាន់អាស័យដ្ឋានត្រឹមតែបញ្ហានេះ រឺយ៉ាងណា?

ទី៣៖ តើ PR មានផ្ទុកនូវការអធិប្បាយគ្រប់គ្រាន់ដើម្បីងាយយល់អំពីកូដរបស់វារឺនៅ?

ទី៤៖ តើកូដមានការមិនគោរពនូវ ភាពត្រឹមត្រូវនៃការត្រលប់ក្រោយរឺទេ? ប្រសិនបើមាន តើ PR header និយាយដូចម្តេច?

ទី៥៖ តើ PR មានផ្ទុកនូវការយល់ស្របរឺទេ? បើមាន តើ PR header និយាយដូចម្ដេច? តើកូដផ្ទុកនូវ trigger_error() statement សម្រាប់ការយល់ស្របនូវ feature?

ទី៦៖ តើភាពស្រប និង ភាពត្រឹមត្រូវនៃការត្រលប់ក្រោយទាំងអស់នោះ គោរពនូវឯកសារក្នុង UPGRADE-X.X.md file ចុងក្រោយរឺទេ? តើការពន្យល់ទាំងអស់នោះផ្ទុកឧទាហរណ៏ “មុន/ក្រោយ” ជាមួយនឹងបែបបទ upgrade រឺទេ?

ដំណាក់កាលទី៥៖ តេស្ដកូដ

យក project របស់អ្នកពីដំណាក់កាលទី៣និងតេស្ដកន្លែងដែល PR ធ្វើការយ៉ាងត្រឹមត្រូវ។ ប្ដូរនូវ Symfony project ក្នុង vendor directory ដោយកូដក្នុង PR ដោយដំណើរការនូវ Git command ដូចខាងក្រោម។ បញ្ចូលនូវ PR ID  សម្រាប់ <ID> placeholders៖

ឧទាហរណ៏

ពេលនេះអ្នកអាច តេស្ដនូវ project ម្ដងទៀតនូវកូដក្នុង PR។

ដំណាក់កាលទី៦៖ Upgrade នូវ PR status

ជាចុងក្រោយ បន្ថែមនូវការអធិប្បាយទៅកាន់ PR។ ត្រូវអរគុណទៅដល់ការចូលរួមចំណែកសម្រាប់ការធ្វើការលើ PR។ បញ្ចូលនូវ Status: <status> ទៅក្នុងការអធិប្បាយដើម្បីបង្ករអោយ Carson Bot របស់យើងដែលជាការ updates នូវ status lable នៃបញ្ហា។