OpenQML workflow about pennylane

[mariaschuld]

Josh and I had a discussion and opened some new issues with essential design decisions that overlap between the assignments. Please post your ideas and problems there! Will be good to communicate more so everyone knows where we stand :)

[co9olguy]

Great, thanks for compiling these :)

[cgogolin]

Thank you Nathan for the clear cut communication, this is much appreciated! Please accept my apologies, I think it was largely only me who created this "mess" on github and who started working outside of their assigned tasks.

I like to put commits on separate issues in their own branch and am used to working with many branches. I would like to keep doing this (because it makes it easier for me to get back into the project when I come back after a week), and because it makes it possible to request merges of different change-sets at different times, but will no longer push these branches to the main repository if you feel that they clutter things too much and will prune the existing branches now.

The ProjectQ plugin in new_user_interface_with_projectQ_plugin is already packaged into a separate python packag and partially adopted to the new API. For now it would be useful to keep it in the the same git repository, as in this way I can still use the plugin API tests that reside there.

When I reached a point where I could no longer continue adopting the plugin without making unwarranted assumptions about which parts of the API are fixed and which will keep changing, I started talking to Josh (in slack and over Skype) on the design of the API. I did that mostly because of two things: First, I felt that I couldn't reasonably continue with my assigned task and, second, I felt that the experience from working on the ProjectQ plugin could be useful for designing the plugin part of the OpenQML API.

[co9olguy]

Hi Christian,

Thanks for understanding, but don't feel the need to take all the responsibility on this one :) There were several "competing" branches submitted by multiple authors.

I received some comments from the team that they were unsure which version of the code was the canonical one, making it hard to move forward on their own work.

I think a good mindset should be "one feature, one branch". So if we count developing a new API as a new feature, then that should all be contained within one branch. Obviously we will always have several branches being developed simultaneously, but if each feature is confined to one branch, it is easier for people to identify single features to single branches.

At the moment, "pruning" means: i) removing multiple branches which target the same feature, and ii) deleting old unused/merged branches. Feel free to keep any branches which delineate independent features.