[RFC] RFC process/management

[nickvergessen]

I think we should narrow it down to: Idea -> Ticket -> Pull Request

• Ideas: idea pops up, users rate it, bikesheeding can be down by the main-audiance
• Ticket: ideas discussion is summed up, details about implementations are discussed
• PR: final discussion of implementation

Area51 would still be used for discussion of the development process, the unstable releases, etc.
But you would not need to read it anymore to get involved into development.

[Nicofuma]

So:

Ideas -> JIRA -> Github
the discussion on the RFC take place on JIRA but if it's too long (so if there is a real concern) we to area51 (we create a discussion topic)

I really like this idea, it make more sense than the actual process (Ideas -> Area51 -> JIRA -> Github) and it's also simpler and more dynamic.

[Nicofuma]

Does someone have something else to propose or any concerns about the latest proposal?

poke

poke

poke

poke

poke

[M.Gaetan89]

What are all those "Poke" quotes in various posts?

[JoshyPHP]

A way to alert people via the notification system.

[M.Gaetan89]

Seems obvious now.
Still not used to this new notifications system.
Thanks

[Marc]

So:

Ideas -> JIRA -> Github
the discussion on the RFC take place on JIRA but if it's too long (so if there is a real concern) we to area51 (we create a discussion topic)

I really like this idea, it make more sense than the actual process (Ideas -> Area51 -> JIRA -> Github) and it's also simpler and more dynamic.

I'd say that's definitely a nicer approach, especially for people that want to get involved.

Bigger changes can still be discussed here while smaller ones will generally just find their way into the core via a ticket + PR.

To be honest, this is IMHO closer to what we have been practising in the last few months anyway.

[brunoais]

I really like this idea, it make more sense than the actual process (Ideas -> Area51 -> JIRA -> Github) and it's also simpler and more dynamic.

I prefer that one.

1. Someone has the idea and posts it in the ideas, while getting some feedback on what it should actually be.
2. A probable implementor does an RFC to get a code discussion on how to get it done.
3. A ticket in the tracker to track the change.
4. A PR in the repository with the actual change in hand.

That looks like the best sequence to make sure it has a new feature has a smooth entering process.
I believe there can be exceptions. E.g.
A popular extension may go directly to RFC.
A bugfix can go directly towards JIRA and github, if no discussion is required, otherwise, directly to the forum.

Comments?
Extra: How much would define a popular extension ?

[Nicofuma]

It looks similar to the current official process, which doesn't work.

I don't think that every RFC needs a big discussion (and actually most of them doesn't need any discussion). That's why I prefer to create the ticket directly and a topic only if necessary.

[RMcGirr83]

I don't think that every RFC needs a big discussion (and actually most of them doesn't need any discussion). That's why I prefer to create the ticket directly and a topic only if necessary.

^ this +1