[RFC 4.0] Create gh project boards for planned 4.0 features

[dneukirchen]

It is currently not very easy to get an overview of the joomla 4.0 development progress.
I see the planned feature list and a lot ungrouped issues / prs, but im not able get a clear overview.

• who is in charge of a feature?
• what is the current state?
• what needs to be done (next)?
• where can i help?
• what is the roadmap of the feature?
• what is the goal?
• technical instructions.

Imo we need some kind of project & resource management.

My suggestion is to use github project boards in a first step (i know there are better tools, but lets not overcomplicate it here). Create at least one project board for each of the planned features (https://developer.joomla.org/roadmap.html) and assign issues / prs to it. Group them by "Todo", "In Progress" and "Done". Feature lead should update the board on a regular basis.

It would be nice if each project/feature also has some kind of readme document to get information about milestones, technical details, involved people and the general mission.

What do you think?

[brianteeman]

Anything is better than nothing

[jeckodevelopment]

It's up to @mbabker and Production Dept.

[mbabker]

I'm cool with it. Honestly, just getting the roadmap page into the state it is in now was a good step forward, but using the project boards helps too (I'm doing it on the downloads site repo, if I ever get around to working on those tasks anyway).

[laoneo]

Perhaps we should move j4 development into its own repo to reduce noise here? It will be easier then to work with projects and issues and assign them to people.

[brianteeman]

Personally thats a much better idea as it makes the tracker much easier to handle. Not sure why it was decided not to do it that way but I assume there was good reason

[mbabker]

Why? It's one thing for feature teams to work in separate repos, but to have a separate repo for each version?

[brianteeman]

a new repo every 4 years isnt much of a hardship ;)

[mbabker]

It breaks continuity. Also, new SVN repos were never set up when jumping 1.0 to 1.5 or 1.5 to the middle ages or then to 3.0. The difference is the issue trackers were fragmented per version.

IMO, that's not a strong argument for a new repo for each major version.

[laoneo]

There was it's own repo for Atum and aurora, so why not making one for the rest? Even media manager and web services do have their own repo.

[dneukirchen]

Imo new repo is not necessary. It might clean up issue tracker, but that can be achieved with proper filtering and project assignments. Creating a new repo does not solve the problems i mentioned in my initial post.

Lets start with project boards and see how that goes.

[laoneo]

What to do then when a project finished?

[dneukirchen]

Then we can close the project, do you see problems with that?

Can i help settings things up?

[mbabker]

There was it's own repo for Atum and aurora, so why not making one for the rest? Even media manager and web services do have their own repo.

Those are project repos meant for bigger feature projects. But the work is still merging back to this main repo when it reaches that state. That's different than having a different repository for a new version of the software.

I've turned the projects board on. I don't remember how GitHub deals with ACL on who can or can't edit it but anyone with access is free to do what they can.

[mbabker]

I've taken a first stab at populating https://github.com/joomla/joomla-cms/projects

Improvements welcome

[brianteeman]

Looking good

[ghost]

@dneukirchen can this issue be closed?

[zero-24]

Closing as the RFC got acepted. 😄 Thanks!