Merging Pull Requests to feature branches when? Why?

[ann0see]

In the past I've merged some pull requests to a feature branch.
I mainly did that to:

1. Archive code which might be interesting in future (and complies with the Jamulus guidelines). Other people might want to take over the work started by someone else so it can be merged in future
2. Give the contributor some kind of attribution (they contributed but either didn't finish or there were unsolved issues which didn't allow us to merge the PR into master)
3. Make the PR tab easier to scan. We can't have stale PRs wait too long.

Volker seemed to do the same (e.g. for the singlemix server or the installer which I later continued. Also the delay pan was similar)

This discussion should clarify when to merge Pull Requests to feature branches, when to close PRs. Furthermore I want to clarify how the branches should be named - and if the contributor should be listed in the main software.

[henkdegroot]

Sounds very nice to have. I think it would be good to have some description associated to the feature branch as well. As the name of the branch may not reveal or might be read differently by some people. Guess if there is an easy method to get to the original PR, that would be nice as well to find the "description".

[ann0see]

Maybe in the README file?

[pljones]

Or a section at the top of the main "README.md" to make it very visible in Github.

[hoffie]

That would make them more visible which is good for creating awareness. At the same time, those branches are frozen. They do not receive bugfixes and may lack features over time (newly listed command line flags will fail to work, etc.). If we list them prominently we should make it very clear that those branches are unsupported and are supposed to be promoted for people who want to continue working on them.

[pljones]

Not in the master README.md - the one on the branch. So "frozen except for a patch to the README.md".

[hoffie]

Ah! I misunderstood. That would be helpful if we go this path, yes.

[hoffie]

1. Archive code which might be interesting in future (and complies with the Jamulus guidelines). Other people might want to take over the work started by someone else so it can be merged in future

Hm, would it be enough if we knew that PRs were guaranteed to stay (e.g. they won't disappear if the submitters branch is deleted)? I think that's the case (but should be checked). I fear that a growing list of feature branches which no (known) intend to continue work on them is getting out of hands.
IOW, if we can stick to PRs, I'd prefer that. They also contain all of the context such as discussions and reviews. Maybe we can add a special label if we wanted to have a quick way to find those.

2. Give the contributor some kind of attribution (they contributed but either didn't finish or there were unsolved issues which didn't allow us to merge the PR into master)

I agree. All of the examples were valuable contributions even if the code has not been merged (yet). I think it's a good idea to ask those contributors if they want to add themselves to the contributors list.

3. Make the PR tab easier to scan. We can't have stale PRs wait too long.

I agree that PRs should be closed if there's no more activity, no one to take over or no consensus if and how it should be implemented.

Volker seemed to do the same (e.g. for the singlemix server or the installer which I later continued. Also the delay pan was similar)

Yes, those are positive examples. :)

[ann0see]

I mean another way would be to merge them to a fork in the @jamulusold account … but that feels very unofficial