Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] AC 12-Nov Meeting Notes

I suggest avoiding adding votes to the bugs. A minus vote from a person in a bug might be interpreted as "no way we are doing that" but as Wayne said the voting is just input for the selection.

Am 18.11.2015 6:01 nachm. schrieb "Wayne Beaton" <wayne@xxxxxxxxxxx>:
Please bear in mind the purpose of this exercise is to identify the areas that we feel should be the focus of FEEP funding. The intent is not for any of these bugs to be even partial statements of work, but rather to provide input to the EMO regarding what we think is important.

Do you think, for example, that solid GTK3 support is more important than improving the Dark Theme?

Of course anything that we can do to provide more detail on bugs or define actual quantifiable work items would be of huge benefit to the process.

Wayne

On 13/11/15 06:20 AM, Marcel Bruch wrote:
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





Am 12.11.2015 um 18:03 schrieb Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx>:

 
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6
 
_______________________________________________
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.

-- 
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.

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon
          Europe 2015

_______________________________________________
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.

Back to the top