Page MenuHomePhabricator

Proposal for project management and communication
Open, Incoming QueuePublic

Description

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.

Related Objects

indefini created this task.Mar 6 2018, 1:45 AM
DaveMDS added a subscriber: DaveMDS.Mar 6 2018, 3:42 AM

Roadmaps are often extremely valuable, although depending on how they're handled they can also be a source of some contention or confusion.

An approach I've seen effectively used is to treat it less as a proscriptive document and more like a descriptive 'forecast' - i.e. a compiled distillation of what the current developers have as plans for their future work individually, overlaid by the larger project's strategic directions.

Another approach differentiates between core "critical path" work that needs coordinated by the project as a whole (e.g. infrastructure changes, major API transitions, etc.) and "planned feature work". The latter can often tend to be a bit more fungible as to when it lands, and can be a bit variable if it depends on a small number of developers whose availability may be hard to predict, so differentiating it can help avoid having the roadmap rapidly get out of date.

In any case, it's great to see some thinking go towards establishing a roadmap; in whatever manner it's done it will be a big benefit to communicate where the project aims to go in the future.

indefini updated the task description. (Show Details)Mar 6 2018, 2:48 PM

Roadmaps are often extremely valuable, although depending on how they're handled they can also be a source of some contention or confusion.

An approach I've seen effectively used is to treat it less as a proscriptive document and more like a descriptive 'forecast' - i.e. a compiled distillation of what the current developers have as plans for their future work individually, overlaid by the larger project's strategic directions.

I think that would be the "project roadmap".

Another approach differentiates between core "critical path" work that needs coordinated by the project as a whole (e.g. infrastructure changes, major API transitions, etc.) and "planned feature work". The latter can often tend to be a bit more fungible as to when it lands, and can be a bit variable if it depends on a small number of developers whose availability may be hard to predict, so differentiating it can help avoid having the roadmap rapidly get out of date.

Ideally this project roadmap would have some items described at "currently being done", "planned", "desired" etc.

In any case, it's great to see some thinking go towards establishing a roadmap; in whatever manner it's done it will be a big benefit to communicate where the project aims to go in the future.

I think most people agree with having roadmap(s), so if it's alright I will open 2 tickets :

  • one for the project roadmap : what should be the contents, where it should be, who is going to take care of it.
  • one for the release roadmap : this one is close to "how to make a release" and I think it needs even more discussion.

I will write this in the ticket roadmap but imho, there should be a rotating release manager if possible, that takes care of the release roadmap too and when the release is done, he should update the project roadmap.
This can be a lot of work, that is why I think it should be a rotating thing unless we can divide the tasks.

jayji added a subscriber: jayji.Mar 7 2018, 7:58 AM
raster added a subscriber: raster.Mar 9 2018, 2:47 AM
Roadmap

I wouldn't go for a per release roadmap. A general one and then simply decide which features will be waited for for the next release. Anything not being waited on means it can happen in parallel but a release isn't going to be blocking on it. It's simpler and more flexible I think.

Move away from Phab

I would say "no". Unless phab is so horribly broken that it justifies the huge effort to move, re-adapt and learn something new only to then discover all if it's different bad points (you'll find it hard to convince me that anything else is better everywhere. It'll be better at some things and worse at others like is almost always the case - convince me otherwise in a very short amount of time as investing time into this is time then not invested in more important things). I say "the devil you know" is far better. Perfect is the enemy of Good. You'll never find perfect. Phab is good. I say stick with it. I don't see anything so insanely bad that justifies the 100's or even 1000's of man hours to move to adapt to and use something else, not to mention the loss of tickets, history, reviews even if some migrate (We did this migration once and frankly the experience from the wiki alone just makes me hate the idea of any kind of move) ... git commit logs with tickets in them won't apply anymore etc. etc..

Give me an overwhelming reason for phab being so bad that we absolutely have to move... then go for it. Otherwise I say than I consider it a distraction.

==== Roadmap ====

I wouldn't go for a per release roadmap. A general one and then simply decide which features will be waited for for the next release. Anything not being waited on means it can happen in parallel but a release isn't going to be blocking on it. It's simpler and more flexible I think.

Maybe not call it a release roadmap but the idea would be to have a ticket that list the features that will be waited and then some. (like the current interfaces ticket)

For example, at the beginning the ticket would describe these features and the general goal of the next release if any (could be discussed and decided in an irc meeting for example). It is also possible that there is nothing notable yet, and the ticket would be empty at the beginning.

Then people start working on their stuff (in a branch?) and if/when they think it can make the release, they put it in the release ticket.
If it's already planned in the release ticket, they can work in master to move fast and break stuff :D

I think It is more or less the same of what is going now?, but maybe with more communication and organization.
This would allow users (and newcomers?) to know who is working on what, and what is currently planned for the release.
It should also ease the work of the release manager as everybody would participate in this ticket that could later act as the release notes.

indefini updated the task description. (Show Details)EditedMar 10 2018, 5:53 PM

I opened a task for the project roadmap : T6768.

I also added some items for discussion in this task:

  • 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.
  • Add a tag like @api_break when you break the beta_api.

I also removed the long terms discussions items: moving away from phab and project manager rotation.

I would like add some input for having a ticket that is updated along the development:
If we want to do a release right now, we don't have a clear idea what was added since last release, we have to ask everyone : "ok we might do a release, is there anything you added that was worth it? any stuff that you need more time?"
If we already add a ticket that sums up what people are doing, we wouldn't need to do this and would win some time.
I think this "release ticket" is the same as communication. It would list the work in progress, what is finished etc... so developers and users can reference to it.

indefini updated the task description. (Show Details)Mar 14 2018, 6:18 PM

It's been one month since the last edit.
I think they are still things undecided here.

Should we wait one more month? or have an 'irc meeting' to discuss more about it?
We can wait one more month but then if it's in the same state as now, maybe we should close this ticket before it gets into limbo.

I like the idea of an IRC meeting. speeds up the round-trips on any discussions.

indefini added a comment.EditedApr 14 2018, 12:33 AM

Like we said on irc, let's make a meeting next weekend if people are up to it.
And let's talk about the possibility of starting a release process too.

@raster if you don't have time to send the email for the irc meeting tell me I will do it.
now for this weekend it is too short? so maybe next weekend?

q66 added a subscriber: q66.EditedApr 18 2018, 1:06 AM

I also like the idea of an IRC meeting. Next or this weekend is good :)

+1 for a meeting.

indefini updated the task description. (Show Details)Apr 18 2018, 8:23 PM
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
raster closed this task as Resolved.Apr 24 2018, 11:03 PM
raster updated the task description. (Show Details)Apr 24 2018, 11:06 PM
raster reopened this task as Open.Apr 24 2018, 11:14 PM
zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:50 AM
zmike edited projects, added efl; removed Restricted Project.Jun 11 2018, 8:58 AM