On 11/1/19 1:29 AM, Luiz Fernando Ranghetti wrote:
Em qua, 30 de out de 2019 às 02:07, Simon Lees
> We realize that this decision will not
make everyone happy but hopefully
> it eventually leads to better group support in the future.
> 2. https://lists.opensuse.org/opensuse-factory/2019-10/msg00263.html
Is this kind of technical decision in the scope of the Board?
 says: "The board should provide guidance and support existing
governance structures, but shouldn't direct or control development,
since community mechanisms exist to accomplish the goals of the
project. The board should document decisions and policies."
If the matter had not been raised with the board then it would not be
within it's scope to deal with. However given that this issue was raised
with the board by parties with strong views on both sides as well as
people caught in the middle unable to do there job "resolving the
conflict" fits within the board's role. In this case the board decided
cleanest solution to the conflict was to recommend a technical solution.
The board is still somewhat limited in its power here, in that we can
not compel people to do work, we can only tell them not to do certain
things which generally is something the board tries to avoid. For
example we can state that groups shall be optional and up to the
maintainer because that is not forcing anyone to do work, likewise if we
felt it was the best solution we could have told maintainers that
submissions that drop the group field won't be accepted.
What we can't do though Is tell everyone that they need to go through
and remove groups likewise we can't tell the yast team that they need to
re add support for groups or tell someone that they must go and
implement something in a certain way. All of these actions would force
someone to do work and we don't have that power.
What we can do though is recommend that if people are interested in
groups, "the following would be a good way" but whether anyone chooses
to go away and implement that is a completely different thing and they
may choose to do something different which would also be fine. But in
this case the fact that there is a better solution played a role in our
(well at least my decision to support the proposal the board put forward).
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B