Contact SV Info Tech about contribution best practices to avoid being caught up in farming

Created on 19 March 2024, 3 months ago
Updated 17 April 2024, 2 months ago

Appears employees of https://www.drupal.org/sv-infotech → have started up posting in bulk README and PHPCS tickets in what can be assumed as a credit farming technique.

SV INFO tech

User = Jasjeet Kaur Brar ( https://www.drupal.org/user/3744942/track → ) has almost 200 around these issues.

Per @D-XPERT they discussed this internally on March 15th 2024 so please only report issues that are after that date.

💬 Support request
Status

Fixed

Component

Spam

Created by

🇺🇸United States smustgrave

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @smustgrave
  • 🇮🇳India D-XPERT

    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!!

  • 🇧🇪Belgium BramDriesen Belgium 🇧🇪

    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?

    It depends a bit on the case I guess. Some maintainers just close the issue immediately as they don't want to have to put work on those kind of issues. But there have been cases (not saying it's the case for SV INFO tech) where issues were being worked on that were 7 year old for a Drupal 7 module. In those cases it would actually be better to triage the issue queue's and just close it as outdated. To be honest, I wouldn't bother with the fact the issue would remain open or not. Putting a lot of effort on those issues is a bit sad, as that capacity could have been used a lot better on contributions that actually make an impact.

    For people new to contributions there is a special issue tag "novice", there are quite some of those issues for Drupal Core. Working on those issues makes a much larger impact, and one that lasts.

    For more senior people it's probably best to pick a module (can be core or contrib) they work with often and check how they can help to improve there. Do note that doing good code reviews is also a meaningful contribution and is often credited for!

    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.

    Credits are a manual task for the maintainer. This used to be somewhat automatic, but unfortunately this was also being gamed by uploading screenshots of patches getting applied correctly. It's true however that this is sometimes forgotten by a maintainer. Best is to pust a comment on the issue then, but make sure it doesn't look like you're begging for a credit. 🙂 I'm not sure how the credit system will look like when we are moving to GitLab issues instead of here on Drupal.org, but I can only imagine it getting better.

    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 :)

    Most of them are listed here: https://www.drupal.org/drupalorg/docs/marketplace/abuse-of-the-contribut... →

    In a nutshell, it's everything that has to do with things that could potentially be automated. E.g. PHPCS, PHPSTAN, readme changes, license/maintainer.txt file changes, info.yml changes to some extent, fixing only typo issues, hook_help issues.

    By the way, good to see a positive vibe!

  • 🇺🇸United States smustgrave
  • 🇮🇳India D-XPERT

    Thank you @Bram for addressing the question and request. Your response is well received.

  • 🇺🇸United States smustgrave

    Yes thank you @D-xpert for the response.

    Can you provide a date that you met with your dev team to address these concern? So we can document in the summary.

    Thanks!

  • 🇮🇳India D-XPERT

    @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 :)

  • 🇺🇸United States smustgrave

    Thanks for providing that! I've updated the issue summary to make sure issues that are before that aren't tracked.

    Appreciate the offer but may not be around on a Saturday but highly encourage members to join our slack community for any questions. Some good channels
    #contribute = probably largest channel and a general purpose one
    #bugsmash = good for those getting started. A daily bug issue will be posted that will need to be triaged. There are bookmarks in the channel
    #frontend = frontend focused :)

    We also have a novice tag for newer users (users with <200 posts) to work on.

    Personally I like to help work on the modules I'm currently using on a project as I can double up.

  • Status changed to Fixed 3 months ago
  • 🇺🇸United States hestenet Portland, OR 🇺🇸

    @D-Expert - thank you so much for following up internally with your team.

    I'll summarize some additional resources which may be useful:

    These are the kinds of resources we are sending to those organizations:

    Resource #1: A video introduction to contribution:
    https://www.youtube.com/watch?v=lu7ND0JT-8A

    Resource #2: A slide deck which goes into greater depth about contribution:
    https://docs.google.com/presentation/d/1jvU0-9Fd4p1Bla67x9rGALyE7anmzjhQ...

    Resource #3: The First Time Contributors Workshop from DrupalCon Pittsburgh
    Part 1: https://www.youtube.com/watch?v=_xxOQu9k9V4
    Part 2: https://www.youtube.com/watch?v=Slm66yXXQ3w

    Resource #4: Issue Etiquette
    https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →

    Resource #5: Credit Abuse Policy
    https://www.drupal.org/drupalorg/docs/marketplace/abuse-of-the-contribut... →

    Our goal is always to provide education and support so that companies and individuals can contribute in meaningful ways.

    I'm going to go ahead and close this issue for now - but we'll re-open it if we catch any other issues that we want to escalate to you to resolve with your team. Please also feel free to reach out for support with contribution training. I'm happy to help.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.69.0 2024