Change Details

This ticket is about possible changes/solutions we could take to make communication and project management better. There is/was discussion on irc/mailing list and I am trying to summarize it. Please discuss any points you'd like. There was some ideas that reached a consensus on irc: **Efl Proposal** 1) When you have a proposal for efl, open a task like this one. 2) Then send an email to the mailing list to notice people about your proposal and possibly subscribe to it if they are interested. <- this step should be automatically done if possible. 3) Discuss on phab. 4) When a decision is reached and the task is closed, a *conclusion* mail is sent to the list (also automatically if possible) The mails to the mailing lists are for reaching the most people possible. Something more difficult if it is just created on phab. The reasons to have the discussion on phab is: - all decisions discussions in one place instead of ml/irc/phab - we can see the status of a discussion (resolved, wontfix etc) - decisions can be referenced with a ticket (no more "there was no discussion about this", "wait let me find the ml thread about this") One problem of phab is it doesn't have threaded discussions. https://secure.phabricator.com/T11451 The mailing list would still be used for everything else. **Roadmap** It was agreed to have an project roadmap : please check the project roadmap task here : T6768. If you think we should have a release roadmap please comment. **Getting something in the release that was not planned in the release roadmap** This section is a little bit sensitive I think, so if something is wrong please tell me. If you want to put something that was not planned in the current release, but you must discuss it first. Open a task and if it gets thumps up by other developers, it will enter the release roadmap. **On checking commits before they get merged** There is not that much build break that we need to block commits. Even if a build breaks, someone with the hw/platform will have to check it anyway. **On merging #e and #edevelop, or get more developers to speak in #e** I don't think this can be done for the moment so I will consider this discussion over for now. (revive it you can) ----------------------------------------- **In discussion/ more ideas** 2018/03/11 edit - Have irc meetings monthly, bi weekly etc. because of timezones have 2 schedules. - Have a developers list on the site (I think nobody opposes this so we could open a ticket about it) - We could encourage review if a developer wants to: developers with commit access could ask for a review even if they can commit direclty. - Jenkins build status should be visible easily, on the site. there is an e-bork list but archives are not viewable right? It was noisy to send to the edevel list but I think it should still send a message to the edevel-list if a platform is not fixed after a fixed delay(1~3days?). Also jenkins bot was kicked out of #edevelop, should it be restored? and make it less verbose? - Open a forum (discourse? not discord) for users, themers, developers. 2018/03/15 edit - When you break/change **beta** api, add a tag to your commit like @api_break (or @beta_break?). So people using the beta apis can see/search the changes and update their application. Raster seems to agree to this, so I will put it in the "has been decided" items if no one disagree. 2018/04/19 edit - After 1 year without a release : evaluate if it is possible and worth starting a release process and do it. If not possible reevaluate regularly (every month?). If you think I should open a task for something specific in this list, please tell me. If something is wrong, tell me and I will edit.

This ticket is about possible changes/solutions we could take to make communication and project management better. There is/was discussion on irc/mailing list and I am trying to summarize it. Please discuss any points you'd like. ===== Conclusions ===== These are the conclusions from the IRC discussion. Please also see V33 for history on this. The below is a cleaned up summary of what was concluded and who will do what. I've tried to make it easy to read to distinguish the original "questions" from "results". > **(Merged top 2 items)** There is a ticket about the **Project Roadmap** (see ticket T6768). Is this enough for now? And always the big question is who maintains it? Do you want more structure beyond this project roadmap? aka a "release roadmap"? I proposed a release roadmap for each release but it might not be the appropriate term, I think it is more like a "release ticket" that has all tasks planned for the release. It could be flexible : you can add stuff, remove or move over to next release. * Start maintaining a TODO ticket for EFL with list of items * Over time convert each item into an actual ticket with description and link to that ticket from the master TODO ticket * Prioritize items in this list (top is higher priority). Also use tickets for that too (fine tune over time) * Each item ticket can have discussions on that item as well as display status and updates * People working on an item take the ticket for it and assign it to themselves * Add a tag for the ticket of either `efl-rel-current`, `efl-rel-next` or `efl-rel-future` * Once a ticket is done it gets a tag of `efl-1.23` or whatever release it went into * @raster will start this ticket * @stefan_schmidt should review this conclusion > From @stephenmhouston: development of a structure plan: determine what the process is for decision making in the project. Who, what, where, when and why and document that. * Discussion first (mailing list or phab - if on phab please advertise on mailing list) * If needed, vote * In vote, 2/3 majority is needed (with a quorum of 7) * @raster has veto > Can/Should we start a release process now for 1.21? * Yes. In the next few weeks after some eo branches merge from @cedric * @stefan_schmidt and @raster will share release duties load * Release stabilization may take a while * Expecting everyone to pitch in to fix bugs for the release * Go back to timed releases (every ~3-6 months, cadence to be determined but perhaps longer than the original 12 weeks we did) > Have IRC meetings monthly, bi weekly etc. because of timezones have 2 schedules. * Bi-weekly if possible. Find a good time slot * Alternate times each meeting to try get as many people able to attend (e.g. one earlier, one later) > We could encourage review if a developer wants to: developers with commit access could ask for a review even if they can commit direclty. * Range of views. Review everything being a solution (e.g. phab) to just stricter controls on who gets commit access (revoking), reviewing some commits and forcing all commits to pass a CI first before going to master. See below in "future discussion". * This will not be decided here as this needs a longer discussion on the mailing list for now > When you break/change beta API, add a tag to your commit like `@api_break` (or `@beta_break`?). So people using the beta APIs can see/search the changes and update their application. Raster seems to agree to this, so I will put it in the "has been decided" items if no one disagree. * Try to put `@beta_break` tags on any changes you make that may break an API even though it is beta/unstable. Normal APIs that are released (e.g. legacy EFL APIs) should not break anyway. > Have a developers list on the site (I think nobody opposes this so we could open a ticket about it) * @raster to figure out a devs page on www > Jenkins build status should be visible easily, on the site. There is an e-bork list but archives are not viewable right? It was noisy to send to the e-devel list but I think it should still send a message to the edevel-list if a platform is not fixed after a fixed delay (1~3days?). Also Jenkins bot was kicked out of #edevelop, should it be restored and make it less verbose? * @stefan_schmidt to figure out alternate infra to run a simple CI build (no make check) environment and test compiling against EFL too in that env * CI bot to be re-allowed on #edevelop for this build > Open a forum (discourse? not discord) for users, themers, developers. * For now: no. More infra and not a pressing need > From @simotek: what should we do with slack. * Drop slack. Tell gustavo to drop the e-slack bot. People can use Matrix for the same purposes for now. ---- ===== Topics for the future ===== * Infra - where to run matrix servers etc. if needed, current status etc. * Code review (or not) discussion to continue on mailing list for now ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ===== Original content here so as to not lose it ===== ---- There was some ideas that reached a consensus on irc: **Efl Proposal** 1) When you have a proposal for efl, open a task like this one. 2) Then send an email to the mailing list to notice people about your proposal and possibly subscribe to it if they are interested. <- this step should be automatically done if possible. 3) Discuss on phab. 4) When a decision is reached and the task is closed, a *conclusion* mail is sent to the list (also automatically if possible) The mails to the mailing lists are for reaching the most people possible. Something more difficult if it is just created on phab. The reasons to have the discussion on phab is: - all decisions discussions in one place instead of ml/irc/phab - we can see the status of a discussion (resolved, wontfix etc) - decisions can be referenced with a ticket (no more "there was no discussion about this", "wait let me find the ml thread about this") One problem of phab is it doesn't have threaded discussions. https://secure.phabricator.com/T11451 The mailing list would still be used for everything else. **Roadmap** It was agreed to have an project roadmap : please check the project roadmap task here : T6768. If you think we should have a release roadmap please comment. **Getting something in the release that was not planned in the release roadmap** This section is a little bit sensitive I think, so if something is wrong please tell me. If you want to put something that was not planned in the current release, but you must discuss it first. Open a task and if it gets thumps up by other developers, it will enter the release roadmap. **On checking commits before they get merged** There is not that much build break that we need to block commits. Even if a build breaks, someone with the hw/platform will have to check it anyway. **On merging #e and #edevelop, or get more developers to speak in #e** I don't think this can be done for the moment so I will consider this discussion over for now. (revive it you can) ----------------------------------------- **In discussion/ more ideas** 2018/03/11 edit - Have irc meetings monthly, bi weekly etc. because of timezones have 2 schedules. - Have a developers list on the site (I think nobody opposes this so we could open a ticket about it) - We could encourage review if a developer wants to: developers with commit access could ask for a review even if they can commit direclty. - Jenkins build status should be visible easily, on the site. there is an e-bork list but archives are not viewable right? It was noisy to send to the edevel list but I think it should still send a message to the edevel-list if a platform is not fixed after a fixed delay(1~3days?). Also jenkins bot was kicked out of #edevelop, should it be restored? and make it less verbose? - Open a forum (discourse? not discord) for users, themers, developers. 2018/03/15 edit - When you break/change **beta** api, add a tag to your commit like @api_break (or @beta_break?). So people using the beta apis can see/search the changes and update their application. Raster seems to agree to this, so I will put it in the "has been decided" items if no one disagree. 2018/04/19 edit - After 1 year without a release : evaluate if it is possible and worth starting a release process and do it. If not possible reevaluate regularly (every month?). If you think I should open a task for something specific in this list, please tell me. If something is wrong, tell me and I will edit.

This ticket is about possible changes/solutions we could take to make communication and project management better. There is/was discussion on irc/mailing list and I am trying to summarize it. Please discuss any points you'd like. ===== Conclusions ===== These are the conclusions from the IRC discussion. Please also see V33 for history on this. The below is a cleaned up summary of what was concluded and who will do what. I've tried to make it easy to read to distinguish the original "questions" from "results". > **(Merged top 2 items)** There is a ticket about the **Project Roadmap** (see ticket T6768). Is this enough for now? And always the big question is who maintains it? Do you want more structure beyond this project roadmap? aka a "release roadmap"? I proposed a release roadmap for each release but it might not be the appropriate term, I think it is more like a "release ticket" that has all tasks planned for the release. It could be flexible : you can add stuff, remove or move over to next release. * Start maintaining a TODO ticket for EFL with list of items * Over time convert each item into an actual ticket with description and link to that ticket from the master TODO ticket * Prioritize items in this list (top is higher priority). Also use tickets for that too (fine tune over time) * Each item ticket can have discussions on that item as well as display status and updates * People working on an item take the ticket for it and assign it to themselves * Add a tag for the ticket of either `efl-rel-current`, `efl-rel-next` or `efl-rel-future` * Once a ticket is done it gets a tag of `efl-1.23` or whatever release it went into * @raster will start this ticket * @stefan_schmidt should review this conclusion > From @stephenmhouston: development of a structure plan: determine what the process is for decision making in the project. Who, what, where, when and why and document that. * Discussion first (mailing list or phab - if on phab please advertise on mailing list) * If needed, vote * In vote, 2/3 majority is needed (with a quorum of 7) * @raster has veto > Can/Should we start a release process now for 1.21? * Yes. In the next few weeks after some eo branches merge from @cedric * @stefan_schmidt and @raster will share release duties load * Release stabilization may take a while * Expecting everyone to pitch in to fix bugs for the release * Go back to timed releases (every ~3-6 months, cadence to be determined but perhaps longer than the original 12 weeks we did) > Have IRC meetings monthly, bi weekly etc. because of timezones have 2 schedules. * Bi-weekly if possible. Find a good time slot * Alternate times each meeting to try get as many people able to attend (e.g. one earlier, one later) > We could encourage review if a developer wants to: developers with commit access could ask for a review even if they can commit direclty. * Range of views. Review everything being a solution (e.g. phab) to just stricter controls on who gets commit access (revoking), reviewing some commits and forcing all commits to pass a CI first before going to master. See below in "future discussion". * This will not be decided here as this needs a longer discussion on the mailing list for now > When you break/change beta API, add a tag to your commit like `@api_break` (or `@beta_break`?). So people using the beta APIs can see/search the changes and update their application. Raster seems to agree to this, so I will put it in the "has been decided" items if no one disagree. * Try to put `@beta_break` tags on any changes you make that may break an API even though it is beta/unstable. Normal APIs that are released (e.g. legacy EFL APIs) should not break anyway. > Have a developers list on the site (I think nobody opposes this so we could open a ticket about it) * @raster to figure out a devs page on www > Jenkins build status should be visible easily, on the site. There is an e-bork list but archives are not viewable right? It was noisy to send to the e-devel list but I think it should still send a message to the edevel-list if a platform is not fixed after a fixed delay (1~3days?). Also Jenkins bot was kicked out of #edevelop, should it be restored and make it less verbose? * @stefan_schmidt to figure out alternate infra to run a simple CI build (no make check) environment and test compiling against EFL too in that env * CI bot to be re-allowed on #edevelop for this build > Open a forum (discourse? not discord) for users, themers, developers. * For now: no. More infra and not a pressing need > From @simotek: what should we do with slack. * Drop slack. Tell gustavo to drop the e-slack bot. People can use Matrix for the same purposes for now. ---- ===== Topics for the future ===== * Infra - where to run matrix servers etc. if needed, current status etc. * Code review (or not) discussion to continue on mailing list for now ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ===== Original content here so as to not lose it ===== ---- There was some ideas that reached a consensus on irc: **Efl Proposal** 1) When you have a proposal for efl, open a task like this one. 2) Then send an email to the mailing list to notice people about your proposal and possibly subscribe to it if they are interested. <- this step should be automatically done if possible. 3) Discuss on phab. 4) When a decision is reached and the task is closed, a *conclusion* mail is sent to the list (also automatically if possible) The mails to the mailing lists are for reaching the most people possible. Something more difficult if it is just created on phab. The reasons to have the discussion on phab is: - all decisions discussions in one place instead of ml/irc/phab - we can see the status of a discussion (resolved, wontfix etc) - decisions can be referenced with a ticket (no more "there was no discussion about this", "wait let me find the ml thread about this") One problem of phab is it doesn't have threaded discussions. https://secure.phabricator.com/T11451 The mailing list would still be used for everything else. **Roadmap** It was agreed to have an project roadmap : please check the project roadmap task here : T6768. If you think we should have a release roadmap please comment. **Getting something in the release that was not planned in the release roadmap** This section is a little bit sensitive I think, so if something is wrong please tell me. If you want to put something that was not planned in the current release, but you must discuss it first. Open a task and if it gets thumps up by other developers, it will enter the release roadmap. **On checking commits before they get merged** There is not that much build break that we need to block commits. Even if a build breaks, someone with the hw/platform will have to check it anyway. **On merging #e and #edevelop, or get more developers to speak in #e** I don't think this can be done for the moment so I will consider this discussion over for now. (revive it you can) ----------------------------------------- **In discussion/ more ideas** 2018/03/11 edit - Have irc meetings monthly, bi weekly etc. because of timezones have 2 schedules. - Have a developers list on the site (I think nobody opposes this so we could open a ticket about it) - We could encourage review if a developer wants to: developers with commit access could ask for a review even if they can commit direclty. - Jenkins build status should be visible easily, on the site. there is an e-bork list but archives are not viewable right? It was noisy to send to the edevel list but I think it should still send a message to the edevel-list if a platform is not fixed after a fixed delay(1~3days?). Also jenkins bot was kicked out of #edevelop, should it be restored? and make it less verbose? - Open a forum (discourse? not discord) for users, themers, developers. 2018/03/15 edit - When you break/change **beta** api, add a tag to your commit like @api_break (or @beta_break?). So people using the beta apis can see/search the changes and update their application. Raster seems to agree to this, so I will put it in the "has been decided" items if no one disagree. 2018/04/19 edit - After 1 year without a release : evaluate if it is possible and worth starting a release process and do it. If not possible reevaluate regularly (every month?). If you think I should open a task for something specific in this list, please tell me. If something is wrong, tell me and I will edit.