Communication between developers about features we're working on about espressopp HOT 9 CLOSED

It depends a little bit you want to share your code or not? Some projects use a next branch, which contains stubs or not fully functional implementations for features to come up in the next major release. The new feature is still developed on a separate feature branch, which get merge into next from time to time.
The advantage is that one can check the next branch for features to come and look for upcoming api changes as well and make multiple features compatible to each other.
Shortly before the next major release nextgets merge into master and new next branch gets started.
However, bugfixes, hotfixes and small changes should still go into master directly, next is more for big features changes which bring a lot of API changes.

from espressopp.

Hi, maybe the easiest way is to open an issue here with the brief description about the new feature. This will be an indication that someone is working on that topic;

from espressopp.

approach that @junghans suggested seems to be a professional way to do this. Are we ready for this?

regarding other communication strategies:

1. We've started to play with @junghans on "Projects" board (here at the top of the page, near "Pull requests"). Under board "Release v2.0" it is planned to collect the features needed to be implemented and bugs needed to be fixed for AdResSo++ v 2.0 :)))
2. I've just created another board, called "Roadmap". I hope the idea of it will be clear if you look at it. There are 4 lists: #Implemented, #WorkingOn, #WaitingFor and #Someday. I put there my Lattice Boltzmann stuff and RATTLE as examples. Lets try to use it and see how it goes. If you are not happy with lists or with the strategy, let me know.
3. And I would like to re-arrange our Wiki and add there "How To's" regarding our policies: how to start with the changes to the code by forking, how to make proper documentation, how to write useful tests, etc.

from espressopp.

@niktre Projects and Roadmaps look great! This was the sort of thing I was imagining when I originally opened this issue. (I was thinking of cases where I'm not even ready to share the code yet.)

For point 3, maybe we could open an issue for each different topic, and then come to a consensus about how we should do things, and put the final decision in the wiki? e.g. I opened an issue about writing unit tests recently, and I was just about to open another about what conditions should be met before accepting a pull request @niktre opened one about pull requests.

from espressopp.

About Roadmap: I don't like we cannot assign different colors to the cards there to indicate who is working on some feature. It may seem to be only a small issue, but it would be convenient.

@acfogarty yes, lets discuss separated issues and I will produce then guides on wiki when we agree on the contents

from espressopp.

@niktre regarding the new roadmap board, is it a "wish list of features" or "enhancements" or "strategy" or a ""to do for an specific method"?

from espressopp.

@govarguz my idea at the moment that we put there things we are currently working on or the ones we are planning to work in the future. There are two possibilities:

1. You want to notify other developers. In this case create a new "note" in the board and stick it to the corresponding list (that's what I done).
2. You want a bit more publicity and some discussion with other developers. In this case open an issue and mark it with blue "enhancement" flag like @acfogarty did on #115 . Then add a "card" to the board linking this issue.

I definitely did not think to put there "wish list of features" (there is no user base, so who should express their wishes?). When it is so far, we can include them into the "Roadmap".

It is also not for "to do for a specific method". To do this one can create another board in "Projects" or to keep everything secret due to whatsoever reason (I do not support this behavior) create a private board in Trello or somewhere else.

In short, for me it is a mixture of "enhancements to existing methods" and "strategic development of new methods". It is not a roadmap in the broad sense, as it is missing solid dates, but the structure of lists should provide an overview on implementation state and priorities.

from espressopp.

@niktre, I agree on the fact that it is no Roadmap but I support the board name e.g. "current/ambitioned enhancements". cheers

from espressopp.

@acfogarty @govarguz ok, I re-engineered the Projects a bit. Now we have a board for "Release Plan" with features to implement in the short-, mid- and longterm releases. We will need to agree what to put inside.

The Roadmap is now called Workload. It is a mixture of open issues that are enhancements or bugs AND notes about enhancements we do or plan to work on (but that are not issues). The notes on enhancements are there for 2 reasons:

1. To notify other developers what we are working or planning to work on and
2. At some point these notes will become either issues or pull requests anyway

from espressopp.