[HyperKitty] #67: RFE: Provide an alternate thread viewer interface
by HyperKitty
#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.
9 years
[HyperKitty] #68: RFE: Change like/dislike system
by HyperKitty
#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.
9 years
[HyperKitty] #50: Handling of users changing Subject lines of threads
by HyperKitty
#50: Handling of users changing Subject lines of threads
------------------------+--------------------------
Reporter: ianweller | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
Sometimes you see this subject line in threads:
Subject: Re: Bar (was: Foo)
My understanding from abompard is that HyperKitty currently does not show
the subject change at all to the user. It should probably at least show
the new subject to the user.
Two ways of potentially dealing with this:
* Where the subject changes in the thread, add it above the first message
(what most mail clients do)
* Make it a different thread (what in some cases might make more sense --
and if it did break a thread incorrectly, you could reattach it, but then
you still want to show the subject line change).
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/50>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
9 years
[HyperKitty] #82: Clarify version numbers in requirements.txt
by HyperKitty
#82: Clarify version numbers in requirements.txt
------------------------+--------------------------
Reporter: sumanah | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
Right now, only a few of the requirements in the requirements.txt files
specify version numbers. I would be happy to add some details with >= so
we are clear about what we are backwards-compatible with -- what should
those numbers be? This will make installation a lot easier.
It looks like we can use the same trick for specifying mailman.client in
the !HyperKitty requirements as in kittystore. Also, I'd particularly like
guidance on the Beautiful Soup installation requirements; given that we
only use Beautiful Soup in a few tests in tests/views/test_thread.py, it
seems to me that we could probably clarify this and only install
beautifulsoup4.
!HyperKitty:
{{{
django-gravatar2
django-social-auth>=0.7.1
djangorestframework>=2.2.0
mailman>=3.0.0b2
kittystore
South
django-crispy-forms
rjsmin
cssmin
robot-detection
pytz
django-paintstore
django-compressor
BeautifulSoup<4.0
django-browserid>=0.10.1
mailmanclient
beautifulsoup4
}}}
kittystore:
{{{
mailman>=3.0.0b2
zope.interface
# sqlalchemy 0.9.8 because this needs to be fixed:
https://bitbucket.org/zzzeek/sqlalchemy/issue/3199/
sqlalchemy>=0.9.8
alembic
# python-dateutil 2.0+ is for Python 3
python-dateutil < 2.0
mock
networkx
Whoosh
dogpile.cache
# mailmanclient is not yet in PyPI
bzr+lp:mailman.client#egg=mailmanclient
}}}
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/82>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
9 years
[HyperKitty] #89: RFE: Consensus tracking/visualisation mechanism
by HyperKitty
#89: RFE: Consensus tracking/visualisation mechanism
------------------------+--------------------------
Reporter: ncoghlan | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
------------------------+--------------------------
https://www.loomio.org/ is an interesting service for collaborative
discussion & decision making. In particular, it has an excellent
visualisation of Apache style consensus:
+1 = thumbs up = Approval
+0 = sideways thumb = Abstention
-0 = thumbs down = Disapproval
-1 = raised hand = Veto
These then get collected into a pie chart. If contributors choose to do
so, they can also include a short 1 line explanation of their position
which then gets embedded below the chart.
The downside of Loomio is that the embedded discussion capability is
relatively limited compared to a full mailing list.
It seems to me it should possible to use some relatively simple markup to
embed a similar feature in mailing list discussions and then visualise it
in HyperKitty. Perhaps even something as simple as:
[+1]
[+1 this will make a nice addition to our feature set]
[-0 I suspect this will cause us maintenance hassles later, but if you
really want to, go ahead]
[-1 this is completely out of scope]
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/89>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
9 years