3 ms·

It looks like your bug tracker is a bunch of pointers into a mailing list. This means: (a) you have no ability to edit entries (or do anything else that email

It looks like your bug tracker is a bunch of pointers into a mailing list. This means: (a) you have no ability to edit entries (or do anything else that email is bad at), (b) the mail interface is frankly hard to read, with everything in uniform monospace font and no formatting, (c) I can't participate or reply on the web interface, I have to sign up for something completely different to participate., and (d) because of the way the site is laid out, I can't see how to get the code, etc. from the bug tracker. I would presumably go back to Google and search for org mode and then try to figure it out from there. But that's just a lot more steps to do what could be made easy. Now, I'm not necessarily super crazy about Github and the like. But for these issues, in my opinion they do a pretty reasonable job. I don't personally think that Github makes PR formatting any harder; I would expect any contributors to use a git command line to look at what they put in the commit message. But at any rate, that's some user education you'll have to do one way or the other. With the current approach, you've got a bunch of other barriers to entry that prevent you from seeing certain users in the first place.

bzg 6y ago
"I can't participate or reply on the web interface, I have to sign up for something completely different to participate" Let me correct this one: no, you don't have to sign up to anything: (1) click on a bug entry on https://updates.orgmode.org https://updates.orgmode.org then (2) click on "try the mailto: link" link. This is other way around: if Org goes to GitLab, GitHub-only users will have to sign up to GitLab just to report an issue, and same for GitHub.
- iLemming 6y ago
  It's not about specific platform. It's about accepting PRs instead of patches.
  - bzg 6y ago
    I hope one day both worlds will reconcile. After all, it should be possible to have PRs sent as patches over a mailing list (and we don't need manual patches to be published as PRs.)
- eslaught 6y ago
  I guess you may have a different viewpoint on this. But from my perspective, that's a context switch, I have to now load up my mail client and be subjected to whatever email arrived since I last opened it. I also don't have "mailto:" hooked up to my actual email client, so that's extra steps for me to get that set up. (Blame me for this if you want to, but I'm guessing that there are probably more people like me in the world than there are people who have their email client set up to handle "mailto:" simply due to the fact that work is required to set it to anything other than the system default.) The question is, what are you filtering for? There are always tradeoffs, and I hope I've demonstrated that the email-based interface is not "free" even for fairly savvy tech users. For less savvy tech users, I'd consider the situation even more difficult.
  - ArneBab 6y ago
    This is my approach: - Copy email eddress - M-x mu4e - S-C C-y C-c RET f <select patch exported with magit> I found just sending an email with my contribution to be a much smoother experience than filing a pull-request. Also M-x org-submit-bug-report
cxr 6y ago
> I don't personally think that Github makes PR formatting any harder GitHub deliberately made GitHub-flavored Markdown incompatible with the way that Markdown dictated line breaks should be handled, although this affects more than just pull requests. In general, the way that people "write" Markdown meant to be published for GitHub is unreadable as plain text, even though it's supposed to be roughly as nice to read raw Markdown as it is to read the rendered form. Many projects' commit logs are also a mess as a result of the way that GitHub pushed their pull-requests-for-everything model on the world. There is no end to the number of projects where every other log entry is a crufty merge commit, and the messages in those projects are generally useless, anyway. Folks shouldn't have to trawl through a disconnected web service to glean the info that should have been included in the commit message but was stuffed into the pull request instead. > Now, I'm not necessarily super crazy about Github and the like. But for these issues, in my opinion they do a pretty reasonable job. I have no horse in any Emacs race, but I agree that proper bugtrackers trump mailing lists. It's just a shame that so many people have consolidated around GitHub (and workalikes, like GitLab and Gogs/Gitea), which is poorly implemented. GitHub implements less-than-optimal workflows for its own reasons, and those reasons generally mirror other Valley-based "social" endeavors, where what's most important is growth, user engagement, and the perception of value at the expense of actual productivity and the adoption of addictive dark patterns to drive it all. Second to the actual mechanics of GitHub is "the GitHub community", which routinely proves to be as much of a liability as an asset. The fact that Emacs is a free software project and GitHub is not and GitHub is only slightly less of a walled garden than Facebook and that its privacy controls (what little it provides, if you want to even try to argue that it provides any) are worse than what Facebook and Twitter provide... ... are all reasons that make for a very bad suggestion to move to GitHub.

bzg 6y ago

"I can't participate or reply on the web interface, I have to sign up for something completely different to participate" Let me correct this one: no, you don't have to sign up to anything: (1) click on a bug entry on https://updates.orgmode.org https://updates.orgmode.org then (2) click on "try the mailto: link" link. This is other way around: if Org goes to GitLab, GitHub-only users will have to sign up to GitLab just to report an issue, and same for GitHub.

iLemming 6y ago
It's not about specific platform. It's about accepting PRs instead of patches.
- bzg 6y ago
  I hope one day both worlds will reconcile. After all, it should be possible to have PRs sent as patches over a mailing list (and we don't need manual patches to be published as PRs.)
eslaught 6y ago
I guess you may have a different viewpoint on this. But from my perspective, that's a context switch, I have to now load up my mail client and be subjected to whatever email arrived since I last opened it. I also don't have "mailto:" hooked up to my actual email client, so that's extra steps for me to get that set up. (Blame me for this if you want to, but I'm guessing that there are probably more people like me in the world than there are people who have their email client set up to handle "mailto:" simply due to the fact that work is required to set it to anything other than the system default.) The question is, what are you filtering for? There are always tradeoffs, and I hope I've demonstrated that the email-based interface is not "free" even for fairly savvy tech users. For less savvy tech users, I'd consider the situation even more difficult.
- ArneBab 6y ago
  This is my approach: - Copy email eddress - M-x mu4e - S-C C-y C-c RET f <select patch exported with magit> I found just sending an email with my contribution to be a much smoother experience than filing a pull-request. Also M-x org-submit-bug-report

cxr 6y ago

> I don't personally think that Github makes PR formatting any harder GitHub deliberately made GitHub-flavored Markdown incompatible with the way that Markdown dictated line breaks should be handled, although this affects more than just pull requests. In general, the way that people "write" Markdown meant to be published for GitHub is unreadable as plain text, even though it's supposed to be roughly as nice to read raw Markdown as it is to read the rendered form. Many projects' commit logs are also a mess as a result of the way that GitHub pushed their pull-requests-for-everything model on the world. There is no end to the number of projects where every other log entry is a crufty merge commit, and the messages in those projects are generally useless, anyway. Folks shouldn't have to trawl through a disconnected web service to glean the info that should have been included in the commit message but was stuffed into the pull request instead. > Now, I'm not necessarily super crazy about Github and the like. But for these issues, in my opinion they do a pretty reasonable job. I have no horse in any Emacs race, but I agree that proper bugtrackers trump mailing lists. It's just a shame that so many people have consolidated around GitHub (and workalikes, like GitLab and Gogs/Gitea), which is poorly implemented. GitHub implements less-than-optimal workflows for its own reasons, and those reasons generally mirror other Valley-based "social" endeavors, where what's most important is growth, user engagement, and the perception of value at the expense of actual productivity and the adoption of addictive dark patterns to drive it all. Second to the actual mechanics of GitHub is "the GitHub community", which routinely proves to be as much of a liability as an asset. The fact that Emacs is a free software project and GitHub is not and GitHub is only slightly less of a walled garden than Facebook and that its privacy controls (what little it provides, if you want to even try to argue that it provides any) are worse than what Facebook and Twitter provide... ... are all reasons that make for a very bad suggestion to move to GitHub.