The google doc for the first round of votes is
available at [1].
Some general thoughts about votings:
Votes should be in between -2 and +2
Some guidance on what I consider a ±2,±1:
+2 means strong preference - I’d champion this FEEP
as much as I can. It’s well scoped and suitable as FEEP project
+1 means weak preference - I’d can imagine this
FEEP will improve the state and may be important to many.
±0 mean no preference - I can’t estimate the
benefits of this feature or am yet undecided
-1 means weak reject - I think this feature is not
very useful or should be started with FEEP at the moment
-2 means strong reject - this feature does not make
sense - at least not to be developed as part of FEEP
Feel free to put short comments
into your voting cells. The can serve as inputs for later
discussion.
If you have additional proposals, please raise a
FEEP bug against Architecture Council and add a line at the
bottom of the table.
I kindly ask you to vote
until Wednesday afternoon. I plan summarize the results on
Thursday morning.
Thank you
Marcel
[1] https://docs.google.com/spreadsheets/d/1mxRX9CCveSgD1abemlBCOAW1zQfyi22HIq7awVfkc_s/edit?usp=sharing
--
Codetrails GmbH
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
