Introduction
Discourse will be applying for the Google Summer of Code event this year. We are a 100% open source discussion platform built for the next decade of the Internet. Our software works as a mailing list, a discussion forum, and a long-form chat room.
Discourse is a from-scratch reboot, an attempt to reimagine what a modern, sustainable, fully open-source Internet discussion platform should be today – both from a technology standpoint and a sociology standpoint. Read more about our project at: http://www.discourse.org/
Important Reading for Prospective Student Applicants
- Keep reading this page to learn about our project ideas for this year.
- Learn how to start coding for Discourse by reading our comprehensive CONTRIBUTING guide.
- Read the Discourse Application Guide for GSoC 2015 today, and be ready when it's time to apply.
- Read about learning Discourse as your first Rails app.
- See some Plugin Examples that will help you get ideas for how you might approach some of our projects this year.
- Ask questions about developing in Discourse on meta.discourse.org, our project discussion site. Spend time browsing the content there, especially the "dev" category.
GSoC Project Ideas & Mentors
Discourse Chat Application
Basic requirements:
- a clearly visible online status for users
- answers should appear on others' view as soon as they are posted
- If possible we should see whenever a user is typing an answer
- Chatrooms?
Implementation:
- Have a special attribute on categories that denotes it to be a "chat" category (advantage, you get all the security stuff totally for free)
- On chat categories only the system can create topics, system creates a new "chat log" topic once a day/week/on N messages.
- You build a new UI for these chat topics, and reuse the existing post creator etc for posting into it.
- If you need XMPP you build a bridge on the server and federate with it, creating posts on Discourse side and mapping users as needed. (people that do not need this can easily opt out)
- You add presence channels into message bus.
This design reuses Discourse's existing infrastructure nicely, you get security, long polling, search and so on without needing to reinvent or create complicated hooks into the system.
Mentors: tba
Further Reading
- https://meta.discourse.org/t/using-discourse-as-a-chat-application/3436
- https://meta.discourse.org/t/chat-plugin-features/24437
Birthday Flair
One feature that might be fun as a plugin (can't see this as core) -- when it is your birthday, show a cake Emoji next to your name.
Reddit does something like this "cakeday" and it's fun. But we could use two possible dates:
-
the day you joined that Discourse (default)
-
your actual birthday, as entered in a custom birthday field in user profile, since we don't -- and have no plans to -- have this field by default
Mentors: tba
Further Reading:
Improve post selection moderator tool
It happens a lot that when splitting topics, you more-or-less need to select all posts downstream of a certain post to get a proper split.
This is a pain in the ass in the current admin interface:
- you have to manually walk down all the posts and click them, though "select+replies" helps a bit.
- the selection UI is crazy slow for reasons I don't fully understand. Like absurdly slow, 1 second wait after each click.
So I suggest we add an "above" and "below" button after "select" to make it easier to select all the posts above or below a certain point in the topic stream:
Warning: @eviltrout said this feature might be hard since the posts you're selecting may not be loaded in the stream.
Mentors: tba
Further Reading:
Add a “merge multiple responses” admin post selection action
For users that insist on posting multiple sequential replies, especially short ones, it would be nice to have a "merge posts" option appear when you use the admin wrench to begin selecting posts in a topic, and then select a few posts by the same user in sequence:
This does make it somewhat ambiguous what happens when 3 different replies "directed" at 3 different users are combined. Not sure exactly how to handle that, but for now I would just remove any explicit replies as part of the combining and come up with some kind of improvement later.
Mentors: tba
Further Reading:
Improved group members management
Following up on the bug that our Admin UI only shows up to 201 members for groups, I'd like to propose the following changes to Group-Admin interface.
allow group editing on user
First, allow direct editing of Groups on User-Admin-Interface (seriously, how is that still missing?):
Replacing the "primary group" feature with the select2-autosuggest for existing groups. I am still unsure about whether or not show the trust groups here, too (as they are not actually editable). And move the primary selection as a two-click select over the pre-selected groups in the into the controls area:
2. Change of User-Management-Layout within Group
The idea is to separate the save-button from the user-management. I'd suggest splitting the screen into half, making the top part about the group settings and the second half the list of the users – working as an endless-scrolling list similar to the admin-user-list. Like this:
Mentors: tba
Further Reading: