2013-06-04, 13:01
Current state :
- Most of internals decisions and goal of the Xbmc Team (In terms of pure coding) are not public even if there's some better thing with the read only forum.
- The Team is made with lot's of people that don't handle the same part of the app and may have some different point of views.
- The current way to add change to Xbmc is fork / code / PR then start a discussion or not. (For both internal and external coders).
- The current dev forums are not completely read by most of the Team guys due to tons of posts and lack of time and posts in JSON thread for example can touch UPnP but the UPnP guys won't read the JSON sub forum.
This leads to lots of problems and time loss for external coders and even for the Team.
As a simple sample : https://github.com/xbmc/xbmc/pull/2773
Adding a recursive parameter to Files.GetDirectory
This feature was on the JSON Todo list : http://forum.xbmc.org/showthread.php?tid=163215 and correspond to a real and normal need.
The recursive feature is already approved and merged for all the other JSON commands.
So a PR is made since this is the way to go.
And the someone jumps in and says I don't want that without taking in account all the fact and then discussion start and nothing will goes further or the PR would be refused.
Leading to strange JSON behavior where everything does not react the same.
Leading also to time loss for all the PR participant starting with the coder of course.
Another sample could be the UPnP file listing, that was working on Frodo, that a patch break , a PR is made to correct this, but someone jumps in and says I don't want to allow this (Even if it was present in Frodo and would lead to a major change between Frodo and Gotham, just chosen by one guy on a PR because the actual way Xbmc works don't fit his needs). Luckily someone else jumps in and give a solution that was accepted (well the initial guy who refused haven't but someone have taken the responsibility to merge).
A last sample : http://forum.xbmc.org/showthread.php?tid=161770 a simple feature that is also in the Todo list and would fit some needs.
Despite multiple attempts to get an answer on this, no one takes the responsibility on it.
Since there's were posts talking about Playlist rework, but no way to get more details on it, it would be stupid to code something it if it was to change soon. So either someone knows that and can tell don't do it or do it the JSON way or do it the full way it's ok.
But impossible to have answers and to start working on it.
And since all Team members can't read all forums and check all PR that are made and all commits that are merged this lead to a terrible situation.
To avoid time loss and more efficiency I've asked multiple time to get some validation and discussion before coding without success.
The only start that was good was the apparition of the JSON Todo list, but no way to have any validation to pick any tasks.
Every asks leads to the same answer : code and see what happens.
And the code and see what happens is a major time loss for both the dev and the Team.
The solution is quite easy to that and handled by ITIL.
A simple and logical approach that would fit in can be :
A Request for Change sub forum and a simple post template, nothing more is needed. (If too many end users jumps in, perhaps a external coders group to limit spam)
Each coder post the template containing :
- What the coder want to add
- Why he want to add
- How he will achieve that
Since all Xbmc part have more or less leads, this would simplify the validations and would limit refusal of PR post coding.
This also allow Xbmc rookies to gives advices, like don't do it like that but like this. Or don't forget the impact on ...
Since all is in a same forum, it's easy for Team members to read and less miss things in the flood of Github or dispersed in the whole forums.
Add Accepted / Rejected in post prefix and it become ultra easy to read.
It also leads to a single point for coders to search history, more easily than checking closed PR or the whole forum.
This can lead to official validation and the Thread can be linked in the PR to limit flood and so each one that don't agree can read the discussion and avoid to start a new one on the same things.
There may be other ways to handle this but this proposal is easy to start and would makes lot's of people gaining lot's of time for near 0 investment.
But whatever solution would be chosen IMO something have to be done.
Long post but I really hope this time a discussion can start and find a solution
PS : My english is still bad so please don't take account on formulations and errors
- Most of internals decisions and goal of the Xbmc Team (In terms of pure coding) are not public even if there's some better thing with the read only forum.
- The Team is made with lot's of people that don't handle the same part of the app and may have some different point of views.
- The current way to add change to Xbmc is fork / code / PR then start a discussion or not. (For both internal and external coders).
- The current dev forums are not completely read by most of the Team guys due to tons of posts and lack of time and posts in JSON thread for example can touch UPnP but the UPnP guys won't read the JSON sub forum.
This leads to lots of problems and time loss for external coders and even for the Team.
As a simple sample : https://github.com/xbmc/xbmc/pull/2773
Adding a recursive parameter to Files.GetDirectory
This feature was on the JSON Todo list : http://forum.xbmc.org/showthread.php?tid=163215 and correspond to a real and normal need.
The recursive feature is already approved and merged for all the other JSON commands.
So a PR is made since this is the way to go.
And the someone jumps in and says I don't want that without taking in account all the fact and then discussion start and nothing will goes further or the PR would be refused.
Leading to strange JSON behavior where everything does not react the same.
Leading also to time loss for all the PR participant starting with the coder of course.
Another sample could be the UPnP file listing, that was working on Frodo, that a patch break , a PR is made to correct this, but someone jumps in and says I don't want to allow this (Even if it was present in Frodo and would lead to a major change between Frodo and Gotham, just chosen by one guy on a PR because the actual way Xbmc works don't fit his needs). Luckily someone else jumps in and give a solution that was accepted (well the initial guy who refused haven't but someone have taken the responsibility to merge).
A last sample : http://forum.xbmc.org/showthread.php?tid=161770 a simple feature that is also in the Todo list and would fit some needs.
Despite multiple attempts to get an answer on this, no one takes the responsibility on it.
Since there's were posts talking about Playlist rework, but no way to get more details on it, it would be stupid to code something it if it was to change soon. So either someone knows that and can tell don't do it or do it the JSON way or do it the full way it's ok.
But impossible to have answers and to start working on it.
And since all Team members can't read all forums and check all PR that are made and all commits that are merged this lead to a terrible situation.
To avoid time loss and more efficiency I've asked multiple time to get some validation and discussion before coding without success.
The only start that was good was the apparition of the JSON Todo list, but no way to have any validation to pick any tasks.
Every asks leads to the same answer : code and see what happens.
And the code and see what happens is a major time loss for both the dev and the Team.
The solution is quite easy to that and handled by ITIL.
A simple and logical approach that would fit in can be :
A Request for Change sub forum and a simple post template, nothing more is needed. (If too many end users jumps in, perhaps a external coders group to limit spam)
Each coder post the template containing :
- What the coder want to add
- Why he want to add
- How he will achieve that
Since all Xbmc part have more or less leads, this would simplify the validations and would limit refusal of PR post coding.
This also allow Xbmc rookies to gives advices, like don't do it like that but like this. Or don't forget the impact on ...
Since all is in a same forum, it's easy for Team members to read and less miss things in the flood of Github or dispersed in the whole forums.
Add Accepted / Rejected in post prefix and it become ultra easy to read.
It also leads to a single point for coders to search history, more easily than checking closed PR or the whole forum.
This can lead to official validation and the Thread can be linked in the PR to limit flood and so each one that don't agree can read the discussion and avoid to start a new one on the same things.
There may be other ways to handle this but this proposal is easy to start and would makes lot's of people gaining lot's of time for near 0 investment.
But whatever solution would be chosen IMO something have to be done.
Long post but I really hope this time a discussion can start and find a solution
PS : My english is still bad so please don't take account on formulations and errors
