-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Post: Life of a JS maintainer #4
Comments
"most people working in the core queue know that any patch touching a JS file needs to have the JavaScript tag if they want a timely review from the JS team. Otherwise there is no way for us to find the issue" I'm curious, I've contributed a very occasional patch to core and I've never realized that JS patches should be tagged as such. Perfect example: https://drupal.org/node/2086981. It's about how publishing options are shown in vertical tab summaries. Since it part of the node module, I classified it as "Component: node system" rather than "Component: JavaScript." In addition, the "Adding tags to issues" help page says that "they are not intended for end users. Maintainers use them to classify posts." It's not until I click through on the "Topical issue tags" tag that I realize that I could have tagged my issue for better visibility to the Javascript team. Did I miss something? Or do we need to change the guidelines around posting issues to Drupal core so that JS issues don't languish? Thanks for posting this! |
That's a perfect example :) Not sure about the guidelines, I mean now you know it and the wording does prevent some level of abuse. It's just that JS is a very special case in the core queue. I don't think we should impact the majority of issues just for this. After all JS is not even 10% of the Drupal code. Now that I'm on the Drupal planet it'll be easier for people to fill in their issues properly, hopefully :) |
I'm no helping much in core issues, but I think you are doing great as JS maintainer. And is good that you learn from your mistakes. You have my respect 👍 With all the experience you have, is normal to start shifting to a role of reviewer/adviser/speaker, and less coding See this Crell's answer in his reddit AMA When are you doing your AMA, btw ? :) |
Thanks :) Yeah I saw the reply from Crell AMA, I still like being in the trenches though. I don't think being as detached would work for me but something more meta is needed for the things I want to do. Hopefully I won't take to much time to find the sweet spot. AMA, why not, if there are people interested. |
Yes, I'm glad your blog is on DP! That's how I can across it and now I know. I'll look to see if there is some new contributor documentation that can be amended to include this information. Considering the number of jQuery devs vs. Drupal devs, I see JS patches as a great way more folks involved with core. (Not to mention improving Drupal's JS code quality!) And, yes, I'll post a 8.x patch in that issue, as requested. :) |
Great, great post. I don't think many other people consider all the pieces of the maintainer guide and take it to heart. I know I don't (ouch). Maintaining multiple core components to the degree that the guide suggests really takes a whole person (or multiple rather). Especially mentoring and growing others. But if you are even barely successful at that, it may take off in itself. I'm happy that Javascript in core is getting there :) Great to have you leading it! |
Very insightful, thanks. I invite people to read the article from a mobile device to see how great it renders, too! |
Comments for Life of a JS maintainer.
The text was updated successfully, but these errors were encountered: