The comment section is great for informing users and the maintainer of something. You can even link to patches or modified files (like the PKGBUILD) there. Past that, I personally don't see a reason to allow users other than the maintainer, just co-maintainers, and TUs/devs to mess with a package base.

While the comments can be used for this, this model creates a divide between package maintainers (and TUs, devs, co-maintainers) and standard users that makes it difficult to quickly and concisely give feedback in the form of code. This impediment to collaboration seems unnecessary given the power of git as a version control tool.

Furthermore it seems roundabout to post a PKGBUILD externally, then have a maintainer download the file, merge it into their repo, and upload it, when instead you could have the workflow of, inspect and merge a request.

For clarity let me describe how I am thinking of this design, and you can give feedback therein:

Each package would have:
* a main git repo: https://aur.archlinux.org/<package_name>.git
** this would have all the properties that the current package repos have
* a collection of forks: https://aur.archlinux.org/<package_name>/<username>.git
** the user would have push/write permission to this repo
** at the create on any fork, it is a clone of the original package
** new ui element to list and view forks
** they could also be implemented like so: https://aur.archlinux.org/<package_name>-<username>.git
*** however this creates a corner case of the user with the name 'git', and could cause nasty collisions between <package>-git and the fork of <package> owned by user git
*** this could be solved by replacing the '-' character with a character that is not valid in a package name, and could bring other complications
* a new ui element to list/view merge requests

user story:
* a non-maintainer user logs in
* they navigate to a package, and would like to suggest a change to a package
* they click a fork button and are given an indication of success or failure of the fork operation
** aurweb clones the package repo into a fresh fork
* they clone this fork locally on their machine, make changes as required, commit code, and push back to their repo on aur.archlinux.org
* they submit a merge request against the main git repo
** some sanity checking that a simple fast-forward merge is all that is required would be helpful
*** if this fails, the merge request should not be submitted
* package maintainer is emailed

package maintainer story:
* maintainer gets notified via email about new merge request
* they login and view the merge request
** this need only need to be a diff of the two last commits on either repo
** but could be more complex, as interfaces on gitlab or github
* they accept or deny the request
** on accept:
*** the main package repo is merged with the user's repo
*** the user's repo is cleared out, as it is no longer needed
**** the user's repo could be saved if space is not an issue
**** but it introduces the increased likelihood of merges that are invalid/cannot be fast-forward merged
**** and it would require that the forks be setup with an upstream remote branch that links to the main package repo
*** the user can be notified about the merge
** on deny:
*** the user is notified via email
*** action is taken on the user's repo
*** choices may be presented to the package manager in the deny dialogue to select from the following, or one could be applied to all denial actions:
**** it is left intact so that they can correct issues
***** these could be deleted but it would make a users workflow harder, especially if the issue was a trivial, but valid, reason for denial
**** it is removed
**** it is marked for removal, then removed at some later date
***** this would help on space without forcing immediate removal for all forks, even those with trivial issues
***** it would help reduce orphaned forks, as everybody forgets
***** it would add computational/storage overhead, to save and check the records

cli user story:

* a user clones a fork package repo that does not exist over ssh with a valid ssh key
** the recognition by aurweb that this is a forked package repo would likely be looking for the sentinel character from before (not '-'), or the fact that they are cloning a repo in a folder, not a root level repo
* aurweb interprets this action as a desire to create a fork of the base package for the user
* the above spin-up steps are preformed to create the forked repo
* the forked repo is offered to the user to be cloned


I apologize for my excessive lack of brevity with this comment, but I think one of the largest strengths of the Arch community is that users are willing to collaborate and give back, and I see this as a logical extension for the AUR package maintenance workflow.


One final note, I realize that what I am proposing is a substantial request, and that if it was to happen it would come much later, but I think that the benefits that come with it justify at least looking into.

You're right, git is a powerful tool and it can be used with patches and is a simpler alternative. When you clone a repository, you are creating your very own repository on the machine you're cloning to. Once you make changes, you can use git-format-patch(1) and/or git-send-email(1) to create/send patches to a maintainer. The maintainer can then merge the patch into their master or reject it.

You're also correct that this would be a fairly large addition to aurweb and it would seem that git has a solution that provides a much simpler alternative, in my opinion.

The problem with using git-send-email is that it would send the patch to the maintainer, but no one else. Often a PKGBUILD on the aur is outdated or broken, and using a PKGBUILD linked to in a comment fixes it. Using a mailing list works too, but I don't think we want aur-general flooded with PKGBUILD patches, nor would that be convenient for someone how just want to get an AUR package to build when the maintainer hasn't updated it but someone else has.

I think something like this might be good, but certainly non-trivial.

I would just link the *.patch in a pastebin.

Alternatively, I am slowly updating my PKGBUILDs with a comment referencing my GitHub "pkgbuilds" repo where merge requests can be sent if needed.
(I regard this as a form of additional convenience.)

...

There was some discussion in the forums about this: https://bbs.archlinux.org/viewtopic.php?id=209593
I never did hear a convincing justification for it.

It seems a lot of work for little to no practical gain.

On the other hand, this offers additional justification for finally fixing  FS#22774 

ids1024: At the end of the day, the maintainer is the one responsible for the package and it is he/she who needs to have any suggested changes to his/her package bases. In the past, I've done what eschwartz suggested and just use git-format-patch to create the patch and upload it to github gists or pastebin then just linking to it in the comments.

I still think it's too large of an addition and the result is not enough to justify the work required, but since this is an open project, anyone can take a stab at making this addition.