“I'm a coder. How can I help with Wget development?”

A very good question!

Despite the fact that Wget is a very, very widely-used program, there are (at the time of this writing) only a very small handful of people helping to develop it. We are in dire need of C programmers!

Getting the Latest Source

First off, you'll need to get a hold of the bleeding-edge source code for GNU Wget; see RepositoryAccess for this. Generally speaking, it's much easier for us to apply patches to Wget that are against the current trunk.

Understanding the Source

It's a good idea to try to familiarize yourself with the layout of the Wget source code, to get a basic feel for where things are and how things are done, so that you have a good idea as to how best to effect whatever changes you're planning to make. An overview of Wget's source code, and how to find your way around in it, is at NavigatingTheSource.

Currently, the way command-line options are handled can be fairly confusing if you're not used to it. Even people who've had to deal with it for a bit can get confused, which is why one of them has contributed a very helpful OptionsHowto. See there for information about finding where a value is set for which command-line option or wgetrc command, and how to add new options.

Finding Something to Work On

Next, if you don't already have in mind what you'd like to do to help with Wget, a great place to start is with by looking at what's currently planned for Wget development, in the BugTracker. You might want to try to fix something that won't be too difficult; use the queries on the BugTracker page that are sorted by Work Required, to find those reports that have been estimated to take "Hours". This will allow you to take on some of the easier tasks as you are familiarizing yourself with the layout of the Wget source code.

If you see something you like, be sure to claim it, so no one else wastes time implementing it. Let the WgetMaintainer know that you plan on implementing it. If a bug shows that it's assigned to a developer, it's probably not available for you to work on. Likewise, if a bug's status is "Needs Discussion", this usually means that there are aspects about it that should be discussed on the list before implementation is attempted. Check for previous threads on the subject, or start a new one, but don't just run in and start coding. When in doubt, it's definitely best to check with the list for how something should be approached.

Checking In With the Group

If you want to make a change that's not currently being tracked in the BugTracker, you should probably check with the group first to make sure it's a good idea, and that there isn't a potentially better way to accomplish the same thing, unless you're just modifying Wget for your own personal benefit.

If you're working on a larger change that will take several days or more, it's a good idea to keep others posted about your work as it progresses; this way you can benefit from the input and advice of others as you work, and minimize the risk of finishing your modifications, only to be told that the quality of your design or code is inadequate for inclusion into the Wget codebase, or that there were some considerations of which you were unaware and that you had neglected to address.

Don't just jump in and start coding (unless it's truly trivial): discuss it first! There might be issues you hadn't thought of, or a problem with the approach you'd like to take, or a misunderstanding of what the bug tracker is talking about. It can save everyone a lot of needless time and work if you take a little time up front to verify things on the MailingList.

Testing, And Submitting A Patch

When you're done with your changes, please be sure to test them before submitting a patch. When you're sure everything is working the way it should be, roll a patch (see PatchGuidelines) and send it to the mailing list bug-wget@gnu.org. You do not have to be subscribed to that list in order to submit patches to it. See also MailingLists.

Assigning Copyright to the Free Software Foundation

The Free Software Foundation, which owns the copyrights for the GNU Wget source code, requires that people who make legally significant (around 15 lines or more) contributions to GNU software (including Wget) sign a contract assigning copyright over the contributions to the FSF, or, if this is not acceptable, to sign papers granting the FSF permission to include the contributions in their software. For this reason, if you submit significant changes to Wget for inclusion, the WgetMaintainer may ask you to assign copyright of them over to the FSF (at which time, details on how to do this will be given).

“What if I don't know how to code?”

You can still help!

Feature Specifications

One great way to help is to look over the FeatureSpecifications page, and either help us nail down what to do to implement a particular feature, or start one on your own. The FeatureSpecifications page usually has some "greyed-out" links; these represent specifications that no one has started to write yet: you're welcome to start it for us! Don't worry about doing a rough or shoddy job; that's the point of having a wiki—we'll iron it out as we go along. You can even add a new specification that's not yet on the FeatureSpecifications page... but you should probably discuss it on the MailingList first to make sure it's something we actually want to do.

Helping write FeatureSpecifications is a great way to pitch in, without having to know anything about programming (typically). You just have to know what you want and how to describe it!

Documentation

Documentation can always be improved. Wget is fortunate to have, in my opinion, very good documentation. It can always be made better. Submitting patches against the Wget Manual is a great way to help improve Wget.

Translations

Wget has been translated into almost 40 different languages (of which only about20 are even remotely up-to-date, five are at or near complete). If you are handy with languages besides English, you can help translate Wget into a new language, or improve one of Wget's current translations.

Translation of Wget's messages are all handled by The Translation Project; if you're interested in helping translate Wget, or fixing existing issues with Wget translation, you need to go there. The Wget developers do not accept patches for translations, we only interact with the Translaton Project for this.

Technical Support

Another great way to help us out is to lurk on the MailingList and on InternetRelayChat, to try to answer users' questions about using Wget. If you're a fairly knowledgeable Wget user, it's a great way to "share the wealth" of your knowledge; if you're not, it's a great way to learn, as you try to help other users with their issues.