Bug Tracker

Modify

Ticket #10611 (closed enhancement: fixed)

Opened 2 years ago

Last modified 2 years ago

It's unclear how to best contribute to jQuery

Reported by: mikesherov Owned by: rwaldron
Priority: blocker Milestone: None
Component: build Version:
Keywords: Cc:
Blocking: Blocked by:

Description

I've been contributing for a bit to this project, and there are just a few pieces of hidden knowledge buried deep in this trac wiki that are always being pointed to when someone new contributes, as if they should have known!

For example, lots of PR's come in without a ticket, or are pull requests on master instead of feature branches. The fact that a ticket needs to be filed first is on this page:  http://docs.jquery.com/Getting_Involved However, that's only linked to from the roadmap page!

Lot's of tickets come in without following the style guidelines, which are located here:  http://docs.jquery.com/JQuery_Core_Style_Guidelines but the only way I found it linked from:  http://docs.jquery.com/JQuery_1.4_Roadmap

I could be wrong, and I might be missing something obvious, but it just seems that more could be done to promote these pages.

Change History

comment:1 Changed 2 years ago by rwaldron

Have you ever googled "contributing to jQuery"? Let me help with that:  http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=contribute+to+jquery

Have you read the readme?  https://github.com/jquery/jquery

This is updated for every release:  http://blog.jquery.com/ (and always includes links to contribute and get started)

This ticket should be changed to "People should look before they leap"

comment:3 Changed 2 years ago by dmethvin

  • Keywords 1.8-discuss added
  • Status changed from new to open
  • Component changed from unfiled to build

I think mikesherov has some legit points here. To us it seems pretty obvious but judging by the number of questions and wayward pull requests we get I think we could definitely explain things better, perhaps just by making the great info we already have more visible, as in the project readme. If we want more help, and I think we do, we need to make it easier to contribute. Or give out more ponies.

Style guide is important but shouldn't be an impediment. If a PR comes in with decent code and test cases I don't have any problem doing a bit of reformatting before committing it. If a frequent contributor is constantly submitting stuff that is not conforming to style it may be different, but on the other hand *I* still make style gaffes too.

I think we can come up with a few simple changes that will help, I've marked this for 1.8 discussion and maybe some people will contribute ideas that way.

comment:4 Changed 2 years ago by mikesherov

I've read the github readme, which has no links to "getting involved" nor "style guide" nor "how to report bugs". Also, No one would think to read the blog as the source of truth for how to contribute. Also, one would have to know that there were specific guidelines to contributing before being compelled to googling it.

"look before you leap" is an appropriate title as rwaldron suggests, because with the current set up, it DOES feel like leaping.. off a cliff.

My goal with this ticket is to make it feel less like a leap, and encourage less unnecessary "submit a ticket first" and "you didn't follow the style guide" pull requests. Of course, if you don't mind it, close this ticket. I am just trying to help.

comment:5 Changed 2 years ago by timmywil

Thanks Mike!

I think it's very valuable to have a fresh perspective on how we can do better to inform people. It will always take coders a little time and we will always need people like Rick to be style nazis (new term), but including information on how to get involved and how to contribute on the github page is a great idea. That is probably the first place developers go when interested in contributing.

Nevertheless, I don't think it's realistic to think that we can be SO good at informing developers on how to contribute they are immediately familiar with the styleguide, the source, the scope of core (or UI or mobile) and its features, its size, etc.

It is incredibly helpful to have a new coder come in and critique the source or a certain way of doing things, but there is also some amount of trust new coders need to have for the more seasoned developers. There have been many instances where a new contributor will come in with some amount of tunnel vision (expectedly) and assume that their solution has not been discussed or is the best possible way to do something or is certainly within the scope of core. And this necessary "vision-widening" will really only happen through spending time in the jQuery community, sitting in #jquery-dev, attending the meetings, etc.

Anyway, maybe I'm getting off-topic now (perhaps I can spark more discussion), but at least links to the bug-patching guidelines, the styleguide, and the getting involved page would be good to have in the README.

comment:6 Changed 2 years ago by mikesherov

Don't get me wrong... I understand all that. I always appreciate code review and the team has been invaluable in getting me up to speed (I'm still not there yet). Deferring to the core team for experience is a must.

As you said, just linking the existing info in more prominent places might be a good start. Thanks again for the feedback.

comment:7 Changed 2 years ago by rwaldron

  • Owner set to rwaldron
  • Status changed from open to assigned

+1 To adding all of those resources directly to the readme - in fact, I'll grab the ticket and make some updates - then have mikesherov review my additions.

Also, everything timmywil said is 100% valid - but how do we convey this?

comment:8 Changed 2 years ago by addyosmani

@rwaldron In addition to the updates being made to the readme to cover the points discussed above, perhaps it would be useful for us to add a few paragraphs regarding expectations (eg. We appreciate the time, effort and interest you are investing in assisting with the project. Whilst we welcome any and all contributions, please note that we are unable to accept all patches or enhancement requests. There are aspects to the project which have been thoroughly explored before and we highly recommend researching on both Trac and past issues before requesting a change be considered).

That said, I feel in ways that we already convey this elsewhere, however I could be wrong.

comment:9 Changed 2 years ago by rwaldron

  • Priority changed from undecided to blocker

Sorry, i forgot about this - I'm going to add some info the readme this weekend.

comment:11 Changed 2 years ago by Rick Waldron

  • Status changed from assigned to closed
  • Resolution set to fixed

Landing pull request 611. Adds Contributing to jQuery Guidelines section to readme. Fixes #10611.

More Details:

comment:12 Changed 2 years ago by dmethvin

  • Keywords 1.8-discuss removed

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.