- Issue created by @smustgrave
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
Adding one issue to the Specbee list where a breaking changes was introduced in a minor module version, by fixing PHPCS issues 🙈
This user only seems to contribute to PHPCS/Readme issues... https://www.drupal.org/user/3721098/track →
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
Okay so Specbee is for sure into the credit farming game. They are digging up 7y+ old issues for D7 modules 🐛 Readme file is missing RTBC to add readme files. There is a pattern in here.
User Nupur Badola → digs up the issues
User ravi kant → creates a MR, usually with errors
User nitin_lama → comes in and fixes most of it, often still with typos or issuesObserved this on a multitude of issues. Users are sometimes mixed, but there are several employees of Specbee active on these issues. Just check the recents posts on the users listed above and open a few issues.
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
Moved my comments from #3431464: Employees of LN Webworks Private Limited posting low contribution tickets in bulk → to this one as it's the company I was talking about.
- 🇮🇳India Shefali Shetty Bangalore
Hi, I’m Shefali and as Specbee’s marketing director, I would like to address this issue on behalf of my company and team members. I’ve been contributing to Drupal since the last 5 years and I’m also a part of Promote Drupal and various DrupalCon marketing committees.
I want to start off by saying that Specbee has over 65+ team members with varied skill sets. While some are quality analysts and new to Drupal who do “dig up” issues to make sure the project is stable, many are Drupal experts who work on core issues and many more complex issues ( reference 1 → , reference 2 → ).
Now, let me come down to the issues called out here and detail it out for you:
📌 Module have PHPCS Issue Needs review -> This issue was not “created” by us. We only tried to “fix” it. Please let me know if there’s something wrong in trying to fix an issue that’s being raised.
📌 Add README File Needs review -> Again, not created by us. Only tried to fix it.
#3335072: Fix the issues reported by phpcs -> Again, not created by us. Only tried to fix it.
📌 Fix the issues reported by phpcs Closed: outdated -> Again, not created by us. Only tried to fix it.Regarding comment #3,
User Nupur Badola digs up the issues
User ravi kant creates a MR, usually with errors
User nitin_lama comes in and fixes most of it, often still with typos or issuesUser Nupur Badola → is a Quality Analyst at Specbee and she helps contribute to the Drupal project by picking out issues that needs a fix. I believe that’s how we make Drupal stronger(?).
Ravi Kant → and Nitin Lama → are frontend and backed developers who have fixed multiple core issues as well. I urge you to go through their profiles in detail to check on their credibility before calling them out like this.While I’m still confused as to why “fixing” Readme file issues is wrong (they’re issues for a reason and someone needs to fix it), I will make sure the team understands the importance of this and we'll go through the Abuse of contribution system with them.
Specbee has been contributing to Drupal since our inception. We always were under the impression that any contribution is good contribution. We really did come for the code and stayed for the community. But this kind of calling out demotivates our team members to make any kind of contributions to the project. I’d appreciate if someone personally reached out to any of the company leadership team members, we’re not hard to find on Slack/LinkedIn/Website.
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
User Nupur Badola is a Quality Analyst at Specbee and she helps contribute to the Drupal project by picking out issues that needs a fix. I believe that’s how we make Drupal stronger(?).
That's a good thing to do. However, I don't think putting a lot of effort in low quality contributions is the way to go. Take the 7 year old D7 issue for example. It doesn't make sense to dig up such issue, and have 2-3 people working on that. In this case it would have been better to triage the issue and close it as outdated (while not getting a credit here, it's a valued contribution to triage issue queues). We have noticed a clear scheme where only those kind of issues are being "picked" to work on. While there are a lot more meaningful contributions under the "novice" tag if you're looking to get new people into contributing.
My message here is, if you want to make an impact, move your teams focus away from readme, PHPCS and .info file changes. And try to work on actual issues that require some level of knowledge of the module/issue. A great place to start is the novice tag (it being core or contrib), but don't get your seniors to work on novice issues!
Ravi Kant and Nitin Lama are frontend and backed developers who have fixed multiple core issues as well. I urge you to go through their profiles in detail to check on their credibility before calling them out like this.
We are not calling out anyone here 🙂 at least that's not our intention! The only thing we are observing are recent activities here, and the thing we see are that the first few pages of posts are mostly only on issues we consider part of the "Abuse of the Contribution Credit system" policy.
Specbee has been contributing to Drupal since our inception. We always were under the impression that any contribution is good contribution. We really did come for the code and stayed for the community. But this kind of calling out demotivates our team members to make any kind of contributions to the project.
I can understand your view here, but don't forget that other people are also looking at your company page and contributions. You must understand that if someone checks the recent credits page, and only sees 100 credits on PHPCS issues how that looks to them. The abuse policy was created because a lot (and I mean really a lot) of module maintainers were starting to get frustrated with the amount of issues that were being created, the time it takes them to comment on these, and the amount of bad quality patches/MR's that were being created (not saying here that this is the case for Specbee).
I’d appreciate if someone personally reached out to any of the company leadership team members, we’re not hard to find on Slack/LinkedIn/Website.
Normally someone should have been contacted from your team by @hestenet, I'll double check with him.
- 🇺🇸United States hestenet Portland, OR 🇺🇸
@smustgrave and @bramdriesen - This is something I probably should have caught in the #contribution-recognition-feedback channel as these issues were being posted.
Todo - I'm assuming they've been told multiple times.
We definitely should not assume that a company has been contacted multiple times or even at all. As a matter of fact, Specbee in particular did receive one message to: @Tanuja Bohra - but it was a very early purely educational email and it was before the credit abuse policy even existed.
For several of the other companies from the meta we know there have been multiple contacts, but we should be very careful if we're not 100% certain - because we don't want to catch people in the cross-fire.
And unfortunately we because people will model their behavior on other behavior they see, we also need to be careful about assuming bad intent - unless we truly *know* an organization has been ignoring documented warnings in the past.
That's at least 90% my fault in this case.
Thank you @Shefali for your measured response - we do know that you and many members of your team are excellent and important contributors.
Thank you @Bram Driesen for your thoughtful reply.
There is likely still outreach we need to do Specbee leadership - I will draft a message - but we want to make sure we are never forgetting to start with assuming good intent and with education and support.
It's only if that advice has been ignored that should treat it as work done with negative intent.
- Status changed to Postponed: needs info
9 months ago 9:02pm 3 April 2024 - 🇺🇸United States hestenet Portland, OR 🇺🇸
I have been in email communication with @Shefali and the Specbee team, and I'm going to mark this issue postponed until we can check in again in a month or two and validate if we're seeing the right kinds of issues chosen for new contributor onboarding.
@Shefali - as you address internal processes with your team, please remember I'm more than happy to assist in training programs. Don't hesitate to ask.
Among other discussion I did include the usual resources:
Resource #1: A video introduction to contribution:
https://www.youtube.com/watch?v=lu7ND0JT-8AResource #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=Slm66yXXQ3wResource #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.
- 🇺🇸United States cmlara
https://www.drupal.org/user/3722731/track → Appears to be targeting “Low effort” D10 Upgrade issues using upgrade status (automated tooling) as primary validation technique.
Most of these modules are likely abandoned given D9 is EOL.
- Status changed to Active
7 months ago 12:07pm 11 May 2024 - 🇺🇸United States cmlara
This example was posted in Slack:
https://www.drupal.org/project/jsonapi_filter_cache_tags/issues/3416953#... 🐛 400 response due to BadRequestHttpException thrown with filter parameter in URL in Drupal 10 Needs workIt was treated as a basic D10 Upgrade Bot issue using automated tooling when it is a scoped issue which is more involved. A report has confirmed the issue is not fully solved contrary to the post by the Specbee user.
The above post was made after my comment #10 which would indicate Specbee may not have developed a robust system to implement oversight.
Adding to the above I went through some of Specbee’s sponsored modules and they have open D10 compatibility issues or other development tickets which this user could be working on rather than targeting the rest of the community.
- 🇺🇸United States hestenet Portland, OR 🇺🇸
I have communicated further with @Shefali on the Specbee side - and she has created a written contribution training and run a virtual training meeting for their contributors internally, with plans to do regular refreshers. She and I continue to be in touch about the content of these.
This is a good step in the right direction, and I appreciate her help with this.
Drupal 10/11 compatibility issues
I did also go ahead and highlight the recent activity on Drupal 10 compatibility issues. Compatibility issues are a valid area of contribution as it is good for the ecosystem to help get those compatibility patches committed, even if the effort is relatively low on a per-issue basis.
However, I highlighted that even for simple compatibility patches:
1) In addition to verifying the patch applies and the module shows as compatible, the contributor should also do a basic check of the module's functionality.
2) This should really be focused on actively maintained modules with some usage - there are some abandoned modules where this effort isn't worth it.
3) The Bot does most of the work here, and like most other contribution tasks that are mostly automated, they are generally less valuable than ones that need the human touch.
4) I also recommended again that contributors try and help with existing open bugs for the maintainer before doing other 'drive by' forms of contribution. - 🇧🇪Belgium BramDriesen Belgium 🇧🇪
New discussion on Slack: https://drupal.slack.com/archives/C0451JV7HRD/p1718816764317369
- 🇩🇰Denmark ressa Copenhagen
Thanks @BramDriesen, maybe you can copy paste the Slack discussion here, for transparency? I don't use Slack, and maybe there are others as well ...
About categorizing README MR's as system gaming by default, see the discussion in 🌱 Categorize contributions that could be considered 'gaming the credit system' and propose solutions (policy, automation, etc) Active .
For README MR's, it's important to separate redundant MR's for 7y+ old issues for D7 modules, as mentioned in #3 by @BramDriesen, and relevant updates to currently actively maintained modules, such as 📌 Replace README.txt with README.md Fixed which was labeled as gaming -- wrongly, in my opinion.
Will fix this directly. These type of tickets are viewed as credit farming and have been reported dozens of times so I’m just closing out
- 🇩🇰Denmark ressa Copenhagen
Updating link in the Issue Summary to point to a D7 README update mentioned in #3 by @BramDriesen:
[...] Specbee is for sure into the credit farming game. They are digging up 7y+ old issues for D7 modules to add readme files
... and not a relevant and perfectly fine README MR, for a current and updated project in 📌 Add README File Needs review . Labeling that as gaming the system is just plain wrong.
- 🇩🇰Denmark ressa Copenhagen
This is the commit by @Nitin Lama from Specbee in the README MR 📌 Add README File Needs review which in my opinion is:
- A clear improvement
- Close to perfect
https://git.drupalcode.org/project/huggingface/-/merge_requests/2/diffs?...
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
Not 100% agreeing with you on that part @ressa. There were cases where 4 different people all of the sudden where jumping on those issues.
1 user commenting on the (old) patch
2 user converts to MR
3 user corrects MR
4 user reviews MR(all different users).
Such activity on a 7y old issue is very suspicious. And their track record unfortunately does not help here. And this was not happening on a single use case. They were actively digging up those issues and doing the same stuff on repeat.
To me, digging up all those issues, and reviving them is not really the issue. But the fact all of the sudden so many people are jumping on them is. If it was one user, who did all the steps correct (reviewing what was done, creating an MR and correcting what's wrong) there is no issue. But it taking 4 people seems odd.
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
As for Slack, tried to place it in a accordion to keep this page condensed:
Slack conversation
cmlara
1 month ago
Opinions on this type of behavior?
https://www.drupal.org/user/3767476/track →
Looks like a lot of low effort issues load a theme, report when one part of a page isn’t styled, or report when a module still uses the Twitter logo instead of the X logo.
To me this is starting to feel like a new method to bulk issues, find something small and likely to occur and work through every module on D.O. to tag the issue.
Not sure that really is much different than the bulk posting of PHPCS issues and I am starting to see it occur more often. Yes they appear to be legit problems, but being loaded in bulk seems like they may fall under “Bulk posting of low-effort issues” the only caveat being they may not be detectable via current publicly avaliable automated tooling.
:face_with_diagonal_mouth:
240 replies
hestenet (he/him)
1 month ago
Yeah. I'm not sure. At a certain point, esp when they aren't automatable - we may have to let some of this kind of stuff go. The overall credit value of these small changes on small modules isn't super high anyway, so maybe we let the relative weighting soak the difference.cmlara
1 month ago
Flip side of that, IIRC it only take 10 contrib fixes and you have the same gain as a massively complex multip year core fix?
I view “bulk low-effort” more like “if you find your organization creating more than 10-20 of the same
Issue in a year it’s probaly a bulk low effort” the count may be debatable, but the fact you have an entire page of the same issue it raises questions.cmlara
1 month ago
Also worth factoring in these than become
Jumping pad issues for other orgs (like the readme issues posted yesterday) where we can see the previously warned orgs jumping on them to “fix” since they didn’t post the issue and are “just fixing open issues to help the maintainer”.hestenet (he/him)
1 month ago
Yeah, true.smustgrave
1 month ago
Think a warning is worthy. Or a no credit as this is novice type tickets. So they should open them and let new users try
Also sent to the channelcmlara
1 month ago
If we do want to allow issues like this maybe it is time to scale the credit cap? Move it from 10 to maybe 100 for Core and scale the rest of the related ecosystem including the partner minimums ?
Runs the risk of even more of these type of issues being opened to counteract a loss in gain however at the same time it might push them to where the issues will at least have the most impact on the community and sends the message “if you really want your organization to be a maker work on Drupal Core”Kristen Pol (she/her)
:palm_tree: 1 month ago
Interesting idea… I’m torn as we also don’t want to stifle innovation for lesser known projects who need buy in from their sponsoring organizations to provide funding to work on thesecmlara
1 month ago
That’s the negative and certainly would have an impact on the smaller modules.
The old “I’m not a partner but my organization can be recognized for the amount of effort I put in” system is going away/gone isn’t it? To be listed I believe now you need to be a Drupal Partner to befit from the point count and if you’re playing in that space I would suspect the organization is likely maintaining the module for a paying customer?
If so the real driver likely is that the customer keeps paying you to develop rather than doing it for the points ?xjm
1 month ago
I mean, on the one hand, things like theming the mini-pager are annoying to do but useful to have done, as an unthemed mini pager screams "hello, I'm a Drupal site and my theme isn't 100% complete". So it is still helpful, or could be. And once someone's made a fix once, I guess they're better poised to help other projects with a similar fix. But it is kind of borderline also.cmlara
1 month ago
Indeed.
I suppose these would annoy me less if we actually had a history of seeing these individuals move from novice to complex issues and that it didn’t feel like this was a game of whack a mole.
With the employee chrun at these mega devs it feels like we usually don’t get to see that happen and usually they make a run through at the novice level and disappear or if they stick around they often do not develop non-novice skill sets (almost like d.o. contrib maintainers are used as a training facility and once they have useable skills they are moved solely to internal customer paying dev work)
I do admit though it is at least nice to see the issues require some effort, even if it is only captcha farm level effort.BramDriesen
1 month ago
The thing that is bugging me however is that Specbee has already been on the radar many times. They just keep finding new things to try every time. Last update here was in may, so just over a month ago… https://www.drupal.org/project/site_moderators/issues/3432186 →Drupal.org
Contact Specbee about contribution best practices to avoid being caught up in farming
Employees of https://www.drupal.org/specbee → have been involved in several README and PHPCS tickets, which are commonly used as credit farming techniques by other companies.
Mar 19th
:point_up:
2Also sent to the channel
kristiaanvde
:factorial: 1 month ago
Would be nice if we could differentiate between changes like these and actual changes. Then have these low-effort issues weigh at around 1:100 of a real issue.
That way, people who want to fix these readmes, icons, etc out of conviction still get the satisfaction of fixing it along with some credit, albeit next to nothing and those who do it to gamify the system will be disincentivized from doing so further.
A checkbox for maintainers only that says "Inconsequential fix" or something that gets picked up by the credit system? I pondered using the severity field and check for "minor" there, but anyone can change that field and then we'd have to police abuse there again.
If we then see Specbee et al create these non-issues on their own projects and leaving the new checkbox blank, we have a lot more to work with to show intent of gaming the system.
:heavy_plus_sign:
5cmlara
1 month ago
I want to reiterate that I’ve seen this tactic showing up on other vendors that we have flagged.
This is not a single user only pattern. I posted this single one just because it was the one I saw today and it seemed more prolific than others I had seen an over the past several months from previously flagged vendors.
:heavy_plus_sign:
1kristiaanvde
:factorial: 1 month ago
No, definitely not. It's a recurring pattern for a handful of companies. At this point, we need tools to discourage this gaming. Credit deductions, the checkbox I suggested, ... anything really to stop the downpour of these non-issuescatch
1 month ago
I think https://www.drupal.org/project/drupalorg/issues/2875806 ✨ Consider weighting issue credits by issue priority when ranking Marketplace organizations Active would cover this without a new checkbox potentially
Drupal.org
Consider weighting issue credits by issue priority when ranking Marketplace organizations
Just as #2833508: Consider weighting issue credits by project usage when ranking Marketplace organizations → creates a little bit more incentive/recognition for working on higher usage projects, I wonder if we should similarly create a little bit more incentive/recognition for working on higher priority issues, because generally, higher priority issues both take more effort and have higher benefit to the project. For example, a relatively weak scale: Minor (0.5), Normal (1), Major (2), Critical (3) Or a stronger scale: Minor (0.33), Normal (1), Major (3), Critical (9)
May 4th, 2017kristiaanvde
:factorial: 1 month ago
Also, I know for a fact that there's a "Belgian team" behind the camps, cons and dev days in Belgium. I'd be surprised if there wasn't one in India.
Seeing as most, if not all, of the culprits are from India, would it be a good idea to reach out to their local Drupal body and ask that they help us figure out why we're seeing so much of these non-issues from massive vendors from a single country? Are they paying their juniors by the issue credit or something?
I know this is risky territory because it may seem like we're being prejudiced towards a specific country, but if your body were to constantly have head aches, we'd investigate the head first rather than the hands, feet and armpits. Might be worth looking into to get a better understanding of why we're seeing such an influx of spam from one location.
:100:
1kristiaanvde
:factorial: 1 month ago
The only issue I have with repurposing the priority field is that it could arguably be something people can hide behind. "Oh, it didn't use to mean that" or "I don't consider this a minor thing" and that anyone can change it.
You could catch people messing with said field, but the fact that it defaults to normal rather than minor would still lead to a lot of these non-issues getting more credit than they should.
Having a new maintainer-only field would make it really clear what the intent is and we could easily run some queries against that to find abuse.
:plus_one:
1cmlara
1 month ago
Drupal Indian Association use to get tagged a lot as the credited organization. I can’t say they planned it, but for a while (before the policy adoption) I saw a lot attributed to them.
I always attributed it to “they want to credit the local governing body” but I always did wonder if the behavior was comming from local camps.cmlara
1 month ago
As somone who isn’t a DCP and has no desire to be a DCP and be listed in the Marketplace:
If somone were to ask me how to choose a partner from the marketplace my advice would probably be “skip the first page or two, theirs some good organizations in there, but many of them make their ranking on bulk easy issues that could often be scripted… if you want an org that only appears to know how to use automated tools go for the first pages, otherwise find someone who is fighting in the trenches lower down in the list who actually knows the internals and look at their issue history and see it’s one off unique fixes not pages of changing a logo or correcting a missing newline at the end of a file”
I may be alone in that mindset, however if any others share a similar view than it should be a distressing sign about the health and validity of the marketplace.BramDriesen
1 month ago
I do follow you in that for a part. What I usually tell is to filter on the “office locations” field as well :slightly_smiling_face: rules out many of the ones we are referring to :stuck_out_tongue:kristiaanvde
:factorial: 1 month ago
I 100% share that view. We put a lot of effort into our contributions and are glad to be on the first page because of it, but it is really disheartening to see 4 companies on page 1 that I know are only there because of a massive amount of non-issues.BramDriesen
1 month ago
Been filtering a bit through issues, I don’t think the priority field will work :slightly_smiling_face: many of the low effort issues are being marked as major or critical :rolling_on_the_floor_laughing:BramDriesen
1 month ago
Apparently a missing readme file which is a copy paste of the project page warrants a critical ticket :man-shrugging:BramDriesen
1 month ago
TBH, when I’m working on issues or committing them, I usually don’t even look at the priority field.kristiaanvde
:factorial: 1 month ago
Apparently a missing readme file which is a copy paste of the project page warrants a critical ticket
That, IMO, would be grounds to take action against whoever set that issue to critical
:plus_one:
3cmlara
1 month ago
I’ll admit a lot of devs probably don’t use it, especially since it can be set by end users.
I do try and use it for my own priority control so I can mange my efforts, however even than I’ll admit the fact that I can’t lock a priority sometimes means I’ll ignore changing it to avoid a fight that I can’t win (looking forward to gitlab on this part)
That said flagging sometbing like a readme conversion (or having a demanding support request) as a critical is a good way to get me to internally flag the user and the org as (for lack of a better word) “troublesome” and goes back to my question recently on “do you find yourself de-prioritizing these flagged organizations”kristiaanvde
:factorial: 1 month ago
Yeah that's why I suggest a checkbox that is flagged by default saying: "This fix is inconsequential", but nicer and more descriptive. Then check it by default.
Or vice versa: "This fix provides actual value and is not just a typo in a readme", but better written and uncheck it by default.
Either way, there should be an active decision to assign credit. We can then run queries against that checkbox and prove intent of gaming the system when people flag readme issues on hardly used modules/themes as "this should definitely get credit"kristiaanvde
:factorial: 1 month ago
Posted that to the issue catch mentioned above.cmlara
1 month ago
I’m reminded of a question a couple months ago regarding a type of simple easy to work issues.
Those of us in this roomed seemed to lean to “don’t credit them it’s farming” while same question in #maintainers leaned towards “it’s small but I would credit that”
Our mindsets certainly play a role in that and any system would have to contend with that ecosystem bias towards “always credit” that many of us in this room have become troubled by.Shefali
25 days ago
Hi, representing Specbee here. I have a few questions just so we are clear what else should we talk to our team about when we have our next contribution guidelines meeting. We've already emphasized the importance of adding value through contributions and ensuring the intent is genuine.
Should the smaller issues be ignored / not worked upon or left for the project maintainers to figure out?
Should we avoid opening issues that need fixes for smaller projects?
What happens when a developer does not have enough expertise to work only on Core/top 100 projects but still intend to make a valuable contribution?
Is it acceptable to highlight genuine issues that appear bulk-submitted due to the same problem existing in many lesser-known projects?
Some of the contributors mentioned are novice contributors/developers who are learning a lot through contributions. I’m not sure asking them to stop such contributions would be the best thing to do, but it seems like we are being encouraged to focus only on high-weightage issues.hestenet (he/him)
25 days ago
I think those are all very legitimate questions, Shefali.
Saved for laterhestenet (he/him)
25 days ago
Curious for some opinions of this group before I weigh in with some more thoughts.Kristen Pol (she/her)
:palm_tree: 25 days ago
One idea is could someone having an “in training” contributor badge / text added when they are new to contributing and that is taken off at some point? Visually being able to tell new people who are learning may be of value.., that doesn’t answer the questions above though
:heavy_plus_sign:
1cmlara
25 days ago
What happens when a developer does not have enough expertise to work only on Core/top 100 projects but still intend to make a valuable contribution?
For organizations they usually “sponsor” modules. That is where I would usually suggest their effort goes, until there are zero issues left in the queues it means there are issues where the org could be directly working ok that are “under their control” any work done there benefits the organization and the community. It also makes any “costs” for training less experienced devs be solely on the organization. These are also a mix of effort required and the more complex issues are perfect for the organizations other developers to mentor the newer developers.
In my personal opinion the contrib queue does not exist to train organizations employees, yet it often feels like inexperienced devs are being sent to us contrib maintainers to train to the point they are skilled devs. Especially on these bulk issuers where I often see even lack of foundational PHP knowledge by some devs.
I usually expect the opposite, that we never see the inexperienced devs because they’re always working internal issues (or issues on the organizations own modules) as that leads to a public image that the organization has skilled employees. Written another way, as a “potential customer” the lowest skilled employee I see publicly working on other modules is what I would assume is going to be a “high skilled” employe that would be assign to my project if I were a paying customer. As a “customer” I’m under no illusion that I have only highly skilled engineers on my coding project, however usually I expect them to be several layers removed from me where an experienced dev audits everything they do before it reaches me.Kristen Pol (she/her)
:palm_tree: 25 days ago
I like the idea of people initially training on issues sponsored by their organization but not everyone is part of an organization or part of one that has sponsored projectscmlara
25 days ago
but not everyone is part of an organization or part of one that has sponsored projects
The majority of these issues we’re looking at with concerns are coming from organizations. It’s rare we see a non-affiliated dev spending their free time bulk creating issues. It’s happened but at the moment on the “educational material” meta it’s a single user vs every other record being an organization IIRC.
As for not having sponsored modules, I would say why not? Look at the internal project list see what is often used, approach the dev see how they feel about adding the sponsor label in exchange for developer time (knowing they may have to guide less knowledgable devs on issues or that they make mistakes but a experienced dev from the org will be auditing their MR’s and guiding them). These solve real world issues that are actually impacting users vs many of these modules that are actually abandoned and not used.Kristen Pol (she/her)
:palm_tree: 25 days ago
Agree that the contribution issues we see are primarily from people at orgs who likely have sponsored projectsxjm
25 days ago
@Shefali
Thanks so much for reaching out. To answer one of your questions, I think one of the most important things is to see contributors growing from "beginner" issues into more advanced contributions. When a user posts the same type of fix to dozens of contributed modules of something that is slightly helpful but fairly trivial, maintainers' reactions will vary, but a lot of maintainers might feel harassed by the issues rather than helped by it. It would be better if contributors gradually work on harder and harder tasks, or worked in pairs with a more senior developer to help meaningfully with harder tasks. (edited)xjm
25 days ago
@Shefali
To share my own story -- Back when I first started out contributing to core, I had spent a lot of time in IRC asking for help about issues I was having with Drupal 7's taxonomy API. Drupal.org added the issue summary field the next month and I was really excited, because writing a summary of an issue was something I could do even though I was intimidated by core code. So I went through and tagged loads of issues "Needs issue summary" and wrote many of the summaries myself. Some core contributors appreciated it, but others were frustrated or even angry with me because it felt like spam to them.
I had the best intentions, but because I did a bulk thing across a huge range of issues, it caused as much unhelpful noise as it helped.
I learned from it and avoided such massive bulk comments in the future (except for a few cases where it was actually necessary due changes in core, and I gave advanced warning that I was going to do so in those cases and did not receive issue credit for it). It's of note though that I did not have the advantage of a large Drupal shop helping me; I was doing it entirely on my own without mentoring or guidance.
So even people who go on to become core committers can make these kinds of slight missteps. :slightly_smiling_face: What's important is to remember that (a) repeated comments or MR submissions that are basically copies of each other can actually make more work for maintainers rather than less, (b) we want to see contributors move on from trivial contributions to more advanced ones after their first few issues, and (c) we especially want to see contributors at organizations that have many other contributors not repeating the same mistakes their peers at the same organization made previously. And (c) is extra extra true for a certified partner. (edited)
:blue_heart:
3Kristen Pol (she/her)
:palm_tree: 18 days ago
Perfect example and takeaways - 🇩🇰Denmark ressa Copenhagen
But ... we agree @BramDriesen :-)
Perhaps I didn't formulate myself clearly .... sorry about that. English is not my primary language. But if you read my comments again, maybe it makes sense? If not, please ask, and I can try to clarify.
Specbee employees may have behaved badly in other issues. All I did was remove the link in the Issue Summary to Huggingface README, since that is a perfectly fine MR, by a Specbee employee ... but it was used as an example of gaming, which it is not.
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
RE #17
Not talking about the improvement which it brings. But don't you find it strange that, such a novice issue, on a quite "random" module, is attracting 4 different users, from 4 different companies, of which multiple have already been warned before? Even some of the users in that issue have also popped up in the past on slack or in the relevant tracking issues. They must be actively searching for those issues, because I never seem to land on those unless I go through that specific modules issue queue and it happens to be on P1.
- 🇩🇰Denmark ressa Copenhagen
But the Huggingface issue is from 23 Feb 2024 ... it's not an old Drupal 7 issue.
I am not sure what to think of the behaviors by these users ... Of course, if a user makes annoying, no-value commits, that should be called out. My point here is merely that in that HuggingFace MR, the Specbee employee behaved exemplary, adding clear value.
Also, if you look at my track record two years ago, I was involved in a lot of README issues, solely to make sure that a consistent template was used, and give Drupal a consistent and professional face on Gitlab via uniform README.md's. So I was indeed following along in all issues and jumped in at relevant README.md issues and made sure the README template was used, during those times when the README update-rush was on, making sure the README template covered the essentials.
As I have stated elsewhere, credit means very little or nothing to me. For example, I have spent a lot of time translating Drupal into Danish, for which I have gotten zero credit. But I did it anyway, simply to improve Drupal, and give back to the community.
- 🇩🇰Denmark ressa Copenhagen
Heh, cross post 🙂 Great that you got my meaning, after reading again. Also, feel free to participate in README discussion in 🌱 Categorize contributions that could be considered 'gaming the credit system' and propose solutions (policy, automation, etc) Active .
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
Also, if you look at my track record two years ago, I was involved in a lot of README issues, solely to make sure that a consistent template was used, and give Drupal a consistent and professional face on Gitlab via uniform README.md's. So I was indeed following along in all issues and jumped in at relevant README.md issues and made sure the README template was used, during those times when the README update-rush was on, making sure the README template covered the essentials.
Oh yes of course! There is nothing wrong with doing that! Documentation is key and the readme is a big part of that. But in most cases the "low effort" cases for the README issues are just a plain copy paste of the old one, or a copy paste from the project description without much change or added value.
README changes are also valid and meaningful contributions for none technical people (as in non-coders). But the added value must be clear of course 🙂.
Thanks for linking that ticket, was already on my watchlist 😉
- 🇺🇸United States hestenet Portland, OR 🇺🇸
Specbee's work to improve their internal contribution standards seems to have been working - I haven't had an escalated issue from one of their staff since this discussion 5 months ago.
Closing this issue for now. It can be re-opened if and when that is necessary.
Thanks to everyone involved, and especially @shefali for leading the internal charge on contribution strategy.
