Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New tools for open source maintainers

blog.github.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: New tools for open source maintainers

#61

Post by jerrac »

dfabulich wrote: post #7

The main thing I want to hide in minimized comments are "+1 fix this plz!" comments on bugs, comments that add nothing above and beyond a thumbs-up reaction. The "reasons" Github offers for minimizing comments are: Spam, Abuse, Off Topic, Outdated, and Resolved. "+1" isn't exactly any of those. (I guess they're kinda "Spam" but they're not unsolicited commercial messages.)

Is there a way for users to easily demonstrate the need/desire for an issue to be fixed to developers? Do developers actually pay attention to how many reactions there are on issues?

If you don't have anything more to add to the discussion, but it seems like the issue is not being considered, a "+1" comment seems like the most effective way to communicate the need to the devs.

Ideally a thumbs up reaction would do the same thing, but does it? Do devs use the sort by "reaction" feature in real life?

I have not yet had the chance to be on the other side. I'm pretty sure I'd check that list occasionally, but I bet I'd forget a lot of the time. Especially if I had a busy project. Sorting by "most recent" or "number of" comments would be more likely. And that would make a "+1" comment more effective.

Re: New tools for open source maintainers

#62

Post by kazinator »

kazinator wrote: post #60
u801e wrote: post #58

Earlier quoted context omitted.

It apparently doesn't present a threaded view like a mail/news client would and downloading the mbox file requires one to authenticate with the server.

Not all mailing list archivers are created equal. For my own site, I rejected the awful Pipermail (default archiver with GNU Mailman) with its brutally ugly presentation format and text-only. I found an alternative called Lurker, with a better web interface and some of the features you're mentioning, like threading. I further customized Lurker. I gave it a button bar with custom icons, and hacked it to support in-lin…

By the way, here is the Lurker author's response to my changes:

https://sourceforge.net/p/lurker/mailman/message/31487163/

TL; DR: Irrationally against all HTML in mail archives, even if properly cleaned. Thanks for Lurker, though!

Re: New tools for open source maintainers

#63

Post by u801e »

anarazel wrote: post #59
u801e wrote: post #58

Earlier quoted context omitted.

It apparently doesn't present a threaded view like a mail/news client would and downloading the mbox file requires one to authenticate with the server.

> It apparently doesn't present a threaded view like a mail/news client would Not the same as a mail client, but once you opened an individual email there's threaded structure. > and downloading the mbox file requires one to authenticate with the server. It does, but also says “Please authenticate with user archives and password antispam” - it's just to make automated extraction of email addresses a bit more work.

> Not the same as a mail client, but once you opened an individual email there's threaded structure.

Yes, but it's much more cumbersome to navigate the thread compared to using an actual mail client. If web pages of mail archives could present an overview pane for navigating messages, it would go a long way to making them usable in a browser as opposed to just posting links to the immediate parent and the set of children for a given message.

Though I wish that having a NNTP gateway (or using NNTP as a primary method of communication for a project) was the standard as opposed to using a mailing list since it would make viewing past messages before subscribing to a newsgroup trivial.

Re: New tools for open source maintainers

#64

Post by u801e »

kazinator wrote: post #60
u801e wrote: post #58

Earlier quoted context omitted.

It apparently doesn't present a threaded view like a mail/news client would and downloading the mbox file requires one to authenticate with the server.

Not all mailing list archivers are created equal. For my own site, I rejected the awful Pipermail (default archiver with GNU Mailman) with its brutally ugly presentation format and text-only. I found an alternative called Lurker, with a better web interface and some of the features you're mentioning, like threading. I further customized Lurker. I gave it a button bar with custom icons, and hacked it to support in-lin…

> http://www.kylheku.com/lurker/message/20121127.210005.0ca78d....

That does look better compared to other web interfaces I've seen in the past (though you still have to hover over the icon to view details of a message like the author and subject).

One decent interface I've seen is public-inbox (https://public-inbox.org/git/). It presents an overview with the subjects and threading and allows for downloading mbox files or using an atom feed link.

Re: New tools for open source maintainers

#65

Post by anarazel »

u801e wrote: post #63
anarazel wrote: post #59

Earlier quoted context omitted.

> It apparently doesn't present a threaded view like a mail/news client would Not the same as a mail client, but once you opened an individual email there's threaded structure. > and downloading the mbox file requires one to authenticate with the server. It does, but also says “Please authenticate with user archives and password antispam” - it's just to make automated extraction of email addresses a bit more work.

> Not the same as a mail client, but once you opened an individual email there's threaded structure. Yes, but it's much more cumbersome to navigate the thread compared to using an actual mail client. If web pages of mail archives could present an overview pane for navigating messages, it would go a long way to making them usable in a browser as opposed to just posting links to the immediate parent and the set of chil…

> Yes, but it's much more cumbersome to navigate the thread compared to using an actual mail client. If web pages of mail archives could present an overview pane for navigating messages, it would go a long way to making them usable in a browser as opposed to just posting links to the immediate parent and the set of children for a given message.

It does, although discovery of the feature as well as the feature itself could use some improvement. In the header there's "Thread:" and the associated button displays the structure. You can also open a whole thread, but I don't find that particularly useful. The download mbox link inside a message will give you the whole thread as well.

Re: New tools for open source maintainers

#66

Post by kazinator »

u801e wrote: post #64
kazinator wrote: post #60

Earlier quoted context omitted.

Not all mailing list archivers are created equal. For my own site, I rejected the awful Pipermail (default archiver with GNU Mailman) with its brutally ugly presentation format and text-only. I found an alternative called Lurker, with a better web interface and some of the features you're mentioning, like threading. I further customized Lurker. I gave it a button bar with custom icons, and hacked it to support in-lin…

> http://www.kylheku.com/lurker/message/20121127.210005.0ca78d... . That does look better compared to other web interfaces I've seen in the past (though you still have to hover over the icon to view details of a message like the author and subject). One decent interface I've seen is public-inbox ( https://public-inbox.org/git/ ). It presents an overview with the subjects and threading and allows for downloading mbox…

The nice thing is that these can be used in parallel. Using Lurker doesn't preclude me from also setting up public-inbox as an alternative presentation of the same archives.

Re: New tools for open source maintainers

#67

Post by justinclift »

claudiulodro wrote: post #25
maxnoe wrote: post #4

Can someone explain the Pull Request restrictions? What does: "the changes are not explained in the commit body" actually mean? Is this opt in?

I believe it's an attempt to stop PRs like this: https://github.com/woocommerce/woocommerce/pull/19545 We get at least one of those a day and they are user error, spam or something. Definitely a useful feature for popular open source projects.

That one (in your URL) looks like the result of a PR between mismatched branches. eg instead of being the intended/correct source and destination branch, it's between two branches fairly far apart.

Thus a shed load of commits to try and resolve the difference.

Hopefully this new behaviour does fix the problem. On the other hand, I have a feeling it might alienate potential contributors who just aren't that familiar with git yet and could instead do with some guidance (ie how to use the correct branch to base changes on).

I guess we get to find out. :)

Post reply on HN