Depending on a user's reputation, they should be able to make multiple arguments per RFC. Every user starts with 1 argument though.

• Show argument counter when a user has more than one argument available
• Notify users somehow when they've passed a reputation threshold and have multiple arguments
• Creating additional arguments is done in the same way: by pressing the vote bar and writing an argument. There should be an explanatory text to let users know they are making another argument

Whenever you hover over a username in the arguments, you should be shown a popup with its relevant user data: name, avatar, social links, reputation

We need to send emails to confirm a user's email address in following scenarios:

• Profile email change
• On login with unconfirmed email
• Registration

RFCs should have two fields: teaser and description

The teaser is used on the homepage, the description on the detail page.

The teaser can only be X-amount of chars long (we'll have to check what looks good on the homepage)

The description should support markdown

Sometimes, because of rounding, the percentages of yes/no don't add up to 100%

You should be able to view a user's profile. It should list

• Reputation
• Public URLs
• A list of all their arguments
• A list of all the arguments they voted for

Some places still need proper meta tags:

• Homepage title
• Homepage description
• Homepage image
• RFC detail page head title

The externals.io rss feed is not really ideal for synchronization of the rfcs sense the link to the rfc in question is not always inside the email when it's being announced for voting and the title doesn't always start with [VOTE] either.

I propose to instead crawl the wiki.php.net/rfc page once a day within a queued job this way we could also crawl the entire rfc content so that the user reading the rfc never actually needs to go the actual php.net page to read it?

This also opens up the possibility to create rfcs which is still in the discussion phase this way the community could start voting the rfcs long before the actual internals voting starts.

It should be rather easy sense the php.net wiki page doesn't heavily rely on javascript.

thoughts @brendt?

Users who've added a website, github profile or website can get verified. Verified means an admin manually approved them, indicating these accounts are legit.

Arguments support markdown, it makes sense to have some kind of editor like https://github.com/Ionaru/easy-markdown-editor

Thinking about how arguments could look.
Full markdown is maybe an overstretch, but I think external links or code snippets could be an interesting option

Related to #1

Also affects arguments highlighting/sorting

A page explaining what this project is about, should also contain a link to GitHub. Should be reachable via the home page, but also via RFC pages, since they'll often be linked directly on social media.

An RSS feed for all the published RFCs

When there's an existing argument for a user, their argument should always be the first in the list.

Furthermore, the argument form should be hidden. A user can choose to edit its argument, which will reopen the argument form.

echo 'hi'

Doesn't work properly

https://externals.io/rss

What do you think if we use Route::view method instead of single responsibility controllers that return only one view?
For example, instead of:

<?php

namespace App\Http\Controllers;

final readonly class AboutController
{
    public function __invoke()
    {
        return view('about');
    }
}

Use this:

// web.php

Route::view('/about', 'about');

It looks cleaner and removes redundant controller files.

We can change a navigation bar to something like this:

Here are some things that we can do related to the nav bar:

1. We can add a PHP logo since this platform is specific for php
2. We can change the font for "rfc votes" logo (later we can make a custom logo)
3. We can change the color of the navbar to dark blue to make more PHP related
4. The navigation bar itself has to have a nav HTML elements instead of the regular div.
5. We can add a container inside the navigation bar to fix the issue on the screenshot below that appears on wide screens:

We can make this dark blue as the main accent color and use it for other elements to make it look more consistent with colors.

I'd like to hear what others think about this.

The meta image of an RFC page should contain the current vote bar, so that people on social media immediately see the current progress.

Much of the value of this platform comes not from the vote counter (which is a basic poll), but from the arguments, and upvotes on those arguments. This data gives much better insights in how the community feels, instead of a simple yes/no vote.

That's why we propose to make some changes:

• The concept of "vote" is removed, instead, a pro or con argument is the only thing a user can submit — essentially: making arguments required.
• The vote bar, however, doesn't show the amount of arguments. It shows the total amount of upvotes on arguments. The pro side is the sum of all upvotes for all pro arguments, the other way around for con arguments. This way, users can still cast a "simple vote" (actually they can cast several); BUT they are forced to read arguments, or even submit one themselves

Open questions:

• We could limit the amount of votes any user has per RFC. This would prevent simply upvoting all pro or con arguments
• This limit could increase based on a user's reputation. Added benefit: this adds an incentive for people to interact.
• We could also increase the amount of arguments a single user can make, a user could even make a pro and con argument if they want to.
• This argument limit again could be increased based on reputation, again adding incentive for people to interact.

Possible problems to overcome:

• Users need to understand that the vote bar shows the total amount of upvotes in the arguments, we need to communicate that clearly somehow.

TODO

• auto update vote counters when argument gets a vote
• #66
• #63
• Clearly explain how voting works on the RFC page
• Minimum argument size
• Be able to switch your vote? Probably requires a new argument.
• Get rid of Vote model once everything is migrated

Right now, meta images are rendered and re-rendered during the request, which is inefficient. It makes more sense to have them render as a queued job, and serve the previous iteration of the meta image. We could then also dispatch this job on RFC creation, meaning there'll always be a meta image available immediately.

I think we need to consider how we handle self-voting. I don't think you should be able to unvote your own argument, but I think it makes sense that, when you make an argument, it counts as a vote. Let's say it's a free vote on top of your limited amount.

So that reputation is updated automatically

tl;dr:

• There should be a clear distinction between yes and no arguments and counters, without solely relying on color
• There shouldn't be a negative connotation to no arguments, it are votes for a no argument, not against it.

The concept of "yes" and "no" is pretty important in this project. However, I feel it's important to no associate any negative connotation with the "no" side, as "no" arguments are equally valid.

For example, it doesn't make sense to style "no" as a downvote, thumbs down or something with -: you're actually voting for a "no" argument, not against it.

For counters, it would be nice if we have another icon or way of visualising the amount of yes and no votes, without using the downwards arrow.

For the vote button on arguments, we now distinguish solely by color. This might not be user friendly enough. I think there should be more distinction between yes and no arguments.

Users should be able to undo their vote

RFCs will be synced automatically, but we still want admin screens to set

• Short description
• End date
• Edit title if necessary
• Published (default is false)

Add the link https://rfc.stitcher.io in this repo's "About" section!

What happens if an argument gets many upvotes, and then gets edited?

• We could disallow edits as soon as an argument has upvotes
• We might allow edits, but with the warning that upvotes will be reset.
• Or we could keep an edit history?

Allow users to

• Change their password
• Set their password when they've logged in via GitHub
• Change their username
• Set an avatar
• Set social media links

Maybe it makes sense to list three other RFCs at the bottom of every RFC page, so that people can keep browsing without going to the homepage.