Added Github Issue Templates

[Sneethe]

Following @mcepl concerns on noise and bloat in the issue tracker,. I added a page to redirect feature request issues to the mailing list. In addition I also added a bug report page that prompts the user for useful information. I also thought it would be a good idea to add the mailing list and IRC to the landing page for more potential eyes on.

Currently you can see what these Issue templates look like here.

Please let me know if these are lacking in anyway. Maybe the Bug Report page could have some parts added/removed.

[mcepl]

Aside from that nit, I think it should be workable.

[rnpnr]

Applied in f41860b. Thanks!

[goyalyashpal]

hi @ mcepl ninewise rnpnr

i saw here too: https://github.com/martanne/vis/pull/1018#issuecomment-1331324729

that the commits are manually applied, rather than merging of the pr. is there any special reason to it? what is the procedure you are following to accomplish that?

i am curious as i am always on the look out of how different people, or different repos manage their contributions and collaboration.

[rnpnr]

hi @ mcepl ninewise rnpnr Hi!

In general I don't use the github interface for applying patches. The process is a little different depending on where the patch came from.

If the patch came as a github pull request:

1. I make a new branch locally
2. I pull directly from the authors repo on github (for this patch git pull git@github.com:Sneethe/vis.git master)
3. If the authors branch wasn't already on the tip of the master branch I rebase it.
4. I then switch back to my local master and use git merge branch-name to apply the change.

If the patch came from email or the mailing list:

1. I use git am < email directly on master

Once that is done I push the updated master to both sourcehut and github.

The criterion on githubs end for having the merged label appear on a pull request is that the commit hash from the merged repo must match the commit hash in the master repo. If I need to rebase the pull request on top of master and the author committed to a separate branch I can force push to their repo so that when I merge the hashes will be the same. Otherwise the hashes will be different and I have to manually close the PR.

(Me explaining this probably gives some good context as to why a lot of people prefer the mailing list based approach.)

[mcepl]

On Tue Dec 26, 2023 at 1:42 PM CET, Charles Tamzarian wrote:

Following @mcepl concerns on noise and bloat in the issue tracker,. I added a page to redirect feature request issues to the mailing list. Thank you for doing this, it is certainly better to have it than not to, you have to understand the lack of passion here, because most people working on vis are advocates of sites like https://sr.ht and email-based development (see https://lists.sr.ht/~martanne/devel). Martanne opened GitHub in the beginning, and we have no hundreds of tickets here, which we cannot get rid of fast enough, but I would be more than happy, if whole development moved to the email list.

Best,

Matěj

-- http://matej.ceplovi.cz/blog/, @@.*** GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8

Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. -- Antoine de Saint-Exupery

[mcepl]

On Wed Jan 24, 2024 at 8:50 PM CET, Randy Palamar wrote:

If the patch came from email or the mailing list:

1. I use git am < email directly on master

https://spacepub.space/w/km8oBzu2qw5V8yhJ3rV1TK

Just a food for thought.

[ninewise]

I usually apply patches from github similar to what is shown in the video linked, so yanking the PR URL, than curl -LOJ url.patch and git am 1160.patch. Someone recently told me github has allowed to do 'rebase and merge' since some time but it used to be just merging which is where I got the habbit. For vis, since we push to sourcehut (via a local copy), it's just easier to do everything there.