@Stephen, This was discussed with team on 15th March and then after this post we had another internal discussion. I have shared
https://www.drupal.org/drupalorg/docs/marketplace/abuse-of-the-contribut... →
link which Bram shared. To explain in more details and make sure team understand we have a session planned on first Saturday of April.
First Saturday of each month is a full day contribution for whole team. You are welcome to be a speaker/mentor for this session :)
Thank you @Bram for addressing the question and request. Your response is well received.
Hi Stephen,
Thank you for posting this because this gives me an opportunity to explain what's actually happening and clear our intention.
We are a team of Drupal developers and working on Drupal based projects for more than a decade now. We started doing contribution and giving back to community since Jan 2023. Team itself is a self starter in terms of doing contribution and to us any contribution is a contribution however we can categorize them in small, med or large the same way we do set priority for any issue e.g. minor, normal, major, critical. We were doing whatever was coming to our way without having a definition of which type of issue we should pick. Team always pick something from latest posted.
I attended the DCP webinar by DA on 5th March 2024 where I got to know that some community members were reporting these Md, phpcs as low contributions and we had an internal discussion later to not work on those type of issues.
After looking at your post I did some calculations with help of team members to get an idea. Numbers would help community to understand our intention as well. Here are the numbers -
Total MD issues we were involved = 182
Total MD issues opened by team = 6
Total phpcs issues we were involved = 120
Total phpcs opened by team = 3
176 MD issues out of 182 were posted by other community members. 117 phpcs out of 120 worked upon were posted by other community members. We majorly worked towards fixing/closing those. When I looked at credits received its less than 25% of total issue worked upon.
We are not opening these type of issues but putting efforts to close them to make the issue queue shorter and clean.
Question - Somebody has to do it or it will always remain there in the issue queue. We did some and you are assuming its a credit farming technique. If anyone else would do it then that community member would be assumed to follow this technique. So according to you who should do it OR you are suggesting lets leave all those issues remain open?
If community feels like these type of issues should not be credited then DA must put a logic in place to not allow giving credit for issue marked as low or normal but then I am afraid such issues would never be closed.
Note - Team members are instructed again not to pick any such issue in any case moving forward but I am aware of some flaws in the credit system e.g. we posted a code patch for a contrib module to fix an issue and maintainer used it and closed without giving credit.
According to me, Credit system must be backed by a strong logic to distribute credits.
Request - Apart from phpcs, md type issue what else you think should be considered as low contribution and we as contributor must not work on such issues? If there is any article on that then please share. We do not want to reported again so asking you so that we can avoid picking those :)
Thank you!!
Good catch !!
It's important to ensure the Packthub API token is properly configured before accessing certain admin pages. This will help prevent any potential issues and ensure the smooth functioning of the system.
This would be a pretty good feature for the module.
Setting the status to NW
@Nitin_lama , I have reviewed the MR the Readme.md file is asper the Drupal recommended template.
Moving it to RTBC.
@benjifisher, thanks for the review. I will work on the suggestions.
All ESLint and Stylelint issues have been addressed.
Kindly review the changes :)
Eslint test now passing.
I will work on this :)
StyleLint now passing.
I will work on this
I have reviewed the changes and tested them in my Drupal 10 DDEV environment. They appear to be okay, and the last GitLab CI run did not flag any new ESLint errors or warnings.
Moving to RTBC.
All styleLint warnings and error have been resolved and the last pipeline test didn't flag any new StyleLint error.
I have updated the forked repository and executed the code sniffer. Here are some warnings that need to be addressed.
FILE: ...var/www/html/web/modules/custom/adc/src/Plugin/Block/DigitalClockBlock.php
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 5 WARNINGS AFFECTING 4 LINES
--------------------------------------------------------------------------------
50 | WARNING | \Drupal calls should be avoided in classes, use dependency
| | injection instead
53 | WARNING | \Drupal calls should be avoided in classes, use dependency
| | injection instead
221 | WARNING | \Drupal calls should be avoided in classes, use dependency
| | injection instead
230 | WARNING | \Drupal calls should be avoided in classes, use dependency
| | injection instead
230 | WARNING | \Drupal calls should be avoided in classes, use dependency
| | injection instead
--------------------------------------------------------------------------------
Time: 174ms; Memory: 12MB
All tests are now passing.
Moving to RTBC
Update the Readme.md with the content that will help the other user to configure and use the module by following this pattern in README.md template → .
Reviewed and tested the MR , while the "configure" key is optional in an info.yml file, MR changes have introduced the configuration option on the extend page.
moving to RTBC.
Reviewed and tested the MR and patch , while the "configure" key is optional in an info.yml file, MR changes have introduced the configuration option on the extend page. Added screenshots for reference.
moving to RTBC.
Reviewed and tested the MR , while the "configure" key is optional in an info.yml file, MR changes have introduced the configuration option on the extend page.
moving to RTBC.
@nikita.gupta, I have installed the module into my Drupal 10 project but didn't encounter the error you mentioned. Added screenshots for reference.
Now Gitab CI is working for automated testing .
Fixed the MR conflicts .
Test are now passing and pipe line is working fine and the failed code style test can be fixed after this is merged.
@larowlan sure , I'd be happy to help you :)
Changed to the correct target branch ,Now test and pipeline is working fine. Although the pipeline has some failed code style test but they can be fixed in follow up tasks after this is merged.
Reviewed the changes and the Gitlab CI pipeline is working now for automated tests . Although there are many failing tests for code styles that can be fixed after this is merged .
Moving it to RTBC.
Reviewed and tested the MR , while the "configure" key is optional in an info.yml file, MR changes have introduced the configuration option on the extend page.
moving to RTBC.
Rest of it looks fine. Moving to RTBC.
Changing the status back to Need work as the changes are not as per the Drupal readme.md template.
Updated issue summary.
Reviewed the MR6 and the changes look good to go. The last pipeline didn't flag any ESLint errors.
I have resolved all the errors and warnings identified by the GIT CI. After fixing them, I executed the GIT CI pipeline, and now all the reported errors have been successfully addressed.
Tested the MR1 . It successfully adds the configuration link to the module extend page.
Same issue is opened here-
https://www.drupal.org/project/ckeditor5_chatgpt/issues/3411881
📌
README.md file missing
Active
Reviewed the changes in MR3. Everything seems good to go. Each section is as per the recommended template by Drupal.
Moving to RTBC !
Thanks.
Changes looks good ,
All Eslint errors seems to be addressed for now.
Ran the Git CI pipeline, and it identified 2 test failures while also highlighting PHPStan errors and warnings. We need to address these issues before proceeding with the merge.
@Nikolay Shapovalov, I have thoroughly reviewed your CSS changes for the style lint, and they have successfully addressed all style lint errors. The latest pipeline run does not report any new style lint errors.
Moving this issue to RTBC
D-XPERT → created an issue.
Added new MR7 with updated README.md as per the Drupal recommended template.
@Hamid.ali, let me help you with this. You need to use 'git mv README.txt README.md' (to rename the file) in your forked project, then make changes to the new README.md file. Add the changes to the staging area using 'git add .', commit the changes with a suitable message using 'git commit', and finally push the changes to the repository.
Hello @Nitin
There is a minor mistake in the heading .
The project name is the only level one heading in the document.
## Permanent Entities:. change it to # Permanent Entities.
Marking from NR to NW as the current changes don't follow the Drupal README.md Template → Standards.
Drupal recommends the following README sections:
Project name and introduction (required)
Table of contents (optional)
Requirements (required)
Recommended modules (optional)
Installation (required, unless a separate INSTALL.md is provided)
Configuration (required)
Troubleshooting & FAQ (optional)
Maintainers (optional)