#66: Restore ability to export mbox files
------------------------+------------------------------
Reporter: dmw | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords: mbox export data
------------------------+------------------------------
Hi there,
After reading about the project on LWN, I was somewhat disappointed to see
there doesn't appear to be mbox export facility yet. As one commenter put
it on the LWN story,
"Download as mbox" or alternatively "download as maildir" are
basically the "liberate the community data" and "allow fast local mirrors
of the archive" functionality for email mailing lists... If it doesn't
have that, it is a show stopper as far as I'm concerned. Maybe a plugin
can fix that, but it is best implemented well integrated with the archive
web interface.
Do you have plans to implement something like this?
Thanks
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/66>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
#79: Highlight messages with best score from one thread
------------------------+--------------------------
Reporter: ttomecek | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
If there is a thread on mailing list which consists of hundreds of
messages, it's almost impossible to read every one of them. Therefore it
could be beneficial to create a view which would contain 3, 5, 10 messages
with best score (with a link to thread view to get a context).
On the other hand, there could be an another way to sort the thread: by
popularity.
I'm not sure which way makes more sense.
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/79>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
#73: Summary page for months and years
------------------------+--------------------------
Reporter: langdon | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
I like the summary page a bunch, however, I wish I could see it for a
month or a year when I click on those nav elements. When going back
through old mailing lists, it is very helpful to get a "sense of the
month" or year.
Or, maybe a "summary icon" next to the month/year nav element, to not lose
the "i just want to get to the emails" feature.
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/73>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
#39: declassification of private mails feature
------------------------+--------------------------
Reporter: misc | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
Since HK is a mail archiver, one of my pet peeve is the various usage of
private mailing list, and what this implies. While a full ACL system could
be nice, I would propre to have a declassification feature.
I have 2 use cases in mind, based on the way i think a community
distribution should work.
First use case is people contacting a project for security reason. While
the content must not be public at first, it could IMHO be made public
after a while ( like automated declassification after 6 months ).
Main reasons are :
- less interest for a potential attacker since less stuff are marked as
private
- more transparency on what happen behind closed doors, reducing the
conspiracy ideas, and permit to people who would learn how the project
react to security issue how stuff happen, even if not in real time. This
is rather important for community growing
The second use case is about all the project that have a private board
list, to discuss private matters. Here, I would rather see a per thread
disclosure feature, after a time.
For example, I could see someone either being a disclosure officer, or on
demand by a admin.
The same benefit as the 1st proposal, this permit to document the decision
of any private group for future reference. But unlike the previous one,
this would not be automatic.
A third way to disclose could be to either just disclose the identity of
the poster, or just identity and subject. This would permit to show to
people ( if they trust the group ) that nothing was discussed for X
months, or who was active ( quite important if the group is elected ).
While this is rather high level idea, while redacting this, i think this
would be best achieved with a rather complete ACL system, but i fear this
is starting to be the sign of feature creep :) ( and i didn't even spoke
of having a tool to discuss disclosure ).
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/39>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
#49: plug-in API
------------------------+-----------------
Reporter: nka11 | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Version: | Keywords:
------------------------+-----------------
Enable plugins and extensions for hyperkitty.
Make it extensible and maybe consider to pull out some integrated features
which could become plugins
- vote +/-
- allow web reply
- tag
- authentication may remains part of core for private lists archives
access.
This have two advantages :
- a well documented plugin API will encourage plugins developers and
contributions to small modules
- the core gets separated from non-pure-ml-archive feature and gets
simpler and easily maintened
- so will become the extra features plugin
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/49>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
#44: 9gag like system for the archive page?
------------------------+--------------------------
Reporter: pingou | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
On the website 9gag.com, the page becomes longer as you scroll down.
Would this be something to consider for the archive page instead of the
current hard-coded pagination?
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/44>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
#74: Gravatar & Profile page
------------------------+--------------------------
Reporter: langdon | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
Might be helpful to indicate on the profile page that "the email address
that your redirect is pointed to" is what we search at gravatar...
in other words, my gravatar image isn't the one at langdon at fp.o, it
actually uses the redirect, langdon at fishjump.c however, "edit at
gravatar" isn't very clear on that.
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/74>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
#78: Hide subthreads with score lower than X
------------------------+--------------------------
Reporter: ttomecek | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
It would be great if !HyperKitty had a feature to hide messages (and its
possible replies) by default which are:
* below a specified score
* marked as spam
* marked as not constructive
With this system we could get smaller thread tree with messages which are
widely-accepted. On the other hand, this system could hide sensible
messages, which may be interesting to read, but community doesn't like
them.
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/78>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
#67: RFE: Provide an alternate thread viewer interface
------------------------+--------------------------
Reporter: duffy | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
Request from LWN article comments (http://lwn.net/Articles/596895/)
"I kinda wish HyperKitty would also offer a threaded hybrid interface in
addition to showing the thread in a messageboard-like fashion.
"Like Gmane does, or slrn, or mutt: The screen split horizontally, with
the upper half showing the subject lines arranged in a threaded hierarchy,
and the lower half showing one message. I personally find that easier and
more logical to navigate."
It would be cool to provide this maybe as a user option; I think I could
make this work with some CSS hackery. I will play around with this and see
if I can come up with anything.
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/67>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
#68: RFE: Change like/dislike system
------------------------+--------------------------
Reporter: duffy | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
Some comments from the LWN article thread
(http://lwn.net/Articles/596820/)
"The like/dislilke should be implemented based on personal preference not
controlled by majority..."
"Advogato's diary ratings got that right, based on its trust metric:
http://advogato.org/trust-metric.html"
" The problem with upvote/downvote/karma systems is that they allow a
majority mindset to establish and stay established. Just look at the
circle-jerks on Hacker News and Reddit (where clever algorithms have had
to be tacked on especially to try to reduce the effects of group-think).
Everyone with a slightly different point of view to the established clique
gets downvoted, and downvoted messages are more likely to attract more
downvotes. People don't click anonymous upvote/downvote buttons because of
reasoned, civil thought, they do it as a deep, primal, emotional, self-
centred reaction. They might do it because $famous_person or $alpha_person
did. They don't think "does this add objective value to the conversation?"
they think "do I agree with this? Does this person's literacy meet my
standards? Do they use C or C++? Do they use emacs or vim? Down with their
opinions!" People are awful. Giving them downvote buttons only enables
their awfulness."
I wonder if it would be possible to swap out how we do the likes/dislikes,
or at least sit down and re-think it. This is one area that has been hard
to test out on the staging server.
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/68>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.