Upgrade StoragePlease define: Create github issue; Pull; Commit; Merge; Closed; etc.
How do these affect current and future versions of Zotero? Visiting GitHub, I see that comments and code have been added. However, I don't understand the implications of the changes for how Zotero will operate for me. I have read several things online about GitHub but I became more confused. Clearly I am missing something basic. Please help me not to feel so foolish and uninformed.
This is an old discussion that has not been active in a long time. Before commenting here, you should strongly consider starting a new discussion instead. If you think the content of this discussion is still relevant, you can link to it from your new discussion.
All git repositories (collections of files corresponding to different aspects of Zotero, like the Zotero client, connectors, word processor plugins, etc.) are hosted under the Zotero project on GitHub. Most of the code relating to the actual Zotero client (both Firefox plugin and Standalone) is found in the zotero repository In this repository Zotero maintains two branches of code (these are related and most of the code is the same): master and 3.0. The 3.0 branch is where all the code that has been (and will be) released under Zotero 3.0 version is located. The master branch contains some additional features that have been planned for Zotero 3.1 or 3.5 or 4.0 (or whatever the version will end up being). Changes to the 3.0 branch are periodically copied over (merged) into the master branch, so that in addition to the new features, the master branch can keep up with any bug fixes that go into the current release.
If someone outside the Zotero core development team wants to make changes to Zotero, they have to get a copy of the code first. On GitHub, you fork a repository to create a copy for yourself on which you can make changes (your copy is called a fork). Every time you make a change to the code, you create a commit. This saves the changes you make to the actual git repository and allows you to add a message describing the changes. This is great for keeping track of changes and being able to revert them if they break something. But these commits are only saved on your fork (copy) of Zotero.
In order for the changes to make it into the official client, you need your commits to be pulled into the main Zotero repository. Zotero developers could find your fork on GitHub and pull the changes in themselves, but this is very time consuming and tedious. That's why GitHub has Pull Requests. Instead of zotero developers looking for the changes you made, you create a Pull Request (which is also considered an issue, see below). Once the Zotero devs look through the changes you propose in the pull request and approve them, all they have to do is click Merge and your changes are copied into the code for official client. If something does not satisfy the devs, they can ask for you to make additional changes (by making more commits) or they can reject the pull request. So just because there is a pull request, doesn't mean that the code changes will make it into the official client. The pull request (or issue) is closed when the code is merged or when the code is rejected.
GitHub also adds ability to keep track of known bugs and feature requests. These are collectively classified as issues. Zotero does not use the GitHub issue tracker for everything that comes up, but issues that have been discussed in the Forums and are not immediately fixed are created on GitHub as a reminder that this needs some work. So basically, if something is not working, post in the forums. Do not create issues on GitHub.
I'm sure I covered a lot of what you already knew, but perhaps this is useful for someone else too.
Edit: fixed some typos
A pull request is a request for someone with write access to the code repository—in the case of the main Zotero codebase, me or Simon—to accept a particular change into a particular branch. You can see on the pull request page whether it's against zotero:master or zotero:3.0. If the pull request is accepted, the change will be available in the next release from that branch. Until the pull request is accepted, the code is not available for use (without using git yourself).
Commit, as a verb, means to add some bit of code to a particular branch. As a noun, it's the set of code changes, with a message attached.
Issues are what they sound like—they track issues—but pull requests also generate issues automatically. Issues can be closed with or without being completed. Some projects use issues for all bug reports and feature requests, but we reserve them for things we're sure we're going to do, meaning that most people should be posting to the forums instead. (If a specific thing has been agreed upon here, we're happy for someone to create an issue for it on GitHub, though.)
Merge is complicated, but the abridged version is that it's pulling one or more commits from one repository into other—e.g., from aurimas's copy of the Zotero codebase into the official repository. When he makes a pull request, he's technically asking us to merge one or more commits from a branch on his own repository of Zotero to a branch on the official one.
There are dev XPIs available for both the 3.0 branch and the master branch. Those aren't currently built automatically, but if I'm around I try to remember to build those as soon as I see a commit on a given branch, meaning that, for example, the 3.0 branch dev XPI will usually contain the latest commits on the 3.0 branch fairly soon after they appear on GitHub.