Policies, or why it's good to know how to change things

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Policies, or why it's good to know how to change things

Antonio Larrosa
Hi all,

We got lots of feedback from you all, also on the process. Many did not
appreciate the long and complicated emails. We discussed this in the
team and Tomáš Chvátal told us how Gentoo shares a nicely documented
change process with Python and Debian already. Essentially, they use a
standardized document which ensures that whenever something has to be
discussed, all information is there right at the start. This shortens
discussions, avoids bikeshedding (see [1]) and afterwards you have a
nice stash of proper proposals in archive.

The proposal is essentially based off of the Python document, simplified
and adapted to openSUSE. It does not change how decisions are made or by
who, just speeds up the process, keeps the discussions clean and
documents their results thus avoiding future flames. We think it would
be great for openSUSE to adapt them.

Attached to this mail there's a draft with a recursive OSEP in the
proper, proposed form, let us know what you think ;-)

Note that the draft we made only proposes to use this for big changes to
our process, not technical things like replacing sysvinit with systemd.

FYI, Agustin has written on our team blog about the proposals, giving an
overview of what's out: http://lizards.opensuse.org/?p=10230

-- The openSUSE Team

[1] http://blog.jospoortvliet.com/2011/09/bikeshedding-and-cls.html

osep-0001-1.png (27K) Download Attachment
OSEP-0001-openSUSE_Enhancement_Proposal.asciidoc (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Henne Vogelsang-2
Hey,

On 11.12.2013 12:00, Antonio Larrosa wrote:

> Attached to this mail there's a draft with a recursive OSEP in the
> proper, proposed form, let us know what you think ;-)

Can you please tell us a couple of real world factory examples where
this would be useful?

Henne

--
Henne Vogelsang
http://www.opensuse.org
Everybody has a plan, until they get hit.
        - Mike Tyson
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Robert Schweikert-6
In reply to this post by Antonio Larrosa
On 12/11/2013 06:00 AM, Antonio Larrosa wrote:

> Hi all,
>
> We got lots of feedback from you all, also on the process. Many did not
> appreciate the long and complicated emails. We discussed this in the
> team and Tomáš Chvátal told us how Gentoo shares a nicely documented
> change process with Python and Debian already. Essentially, they use a
> standardized document which ensures that whenever something has to be
> discussed, all information is there right at the start. This shortens
> discussions, avoids bikeshedding (see [1]) and afterwards you have a
> nice stash of proper proposals in archive.
>
> The proposal is essentially based off of the Python document, simplified
> and adapted to openSUSE. It does not change how decisions are made or by
> who, just speeds up the process, keeps the discussions clean and
> documents their results thus avoiding future flames. We think it would
> be great for openSUSE to adapt them.
>
> Attached to this mail there's a draft with a recursive OSEP in the
> proper, proposed form, let us know what you think ;-)
>
> Note that the draft we made only proposes to use this for big changes to
> our process, not technical things like replacing sysvinit with systemd.
>
> FYI, Agustin has written on our team blog about the proposals, giving an
> overview of what's out: http://lizards.opensuse.org/?p=10230
>
> -- The openSUSE Team
>
> [1] http://blog.jospoortvliet.com/2011/09/bikeshedding-and-cls.html
>


Do we really need to discuss yet another topic that is only tangentially
related to the things we have already started, release cycle, openQA,
and changes to Factory?

I think this can wait until some of the other basic stuff is sorted out.

We really do not have to discuss all the topics at the same time.

Later,
Robert

--
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
Public Cloud Architect
[hidden email]
[hidden email]
781-464-8147
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Michal Vyskocil-2
In reply to this post by Antonio Larrosa
On Wed, Dec 11, 2013 at 12:00:25PM +0100, Antonio Larrosa wrote:

> Hi all,
>
> We got lots of feedback from you all, also on the process. Many did not
> appreciate the long and complicated emails. We discussed this in the
> team and Tomáš Chvátal told us how Gentoo shares a nicely documented
> change process with Python and Debian already. Essentially, they use a
> standardized document which ensures that whenever something has to be
> discussed, all information is there right at the start. This shortens
> discussions, avoids bikeshedding (see [1]) and afterwards you have a
> nice stash of proper proposals in archive.
>
> The proposal is essentially based off of the Python document, simplified
> and adapted to openSUSE. It does not change how decisions are made or by
> who, just speeds up the process, keeps the discussions clean and
> documents their results thus avoiding future flames. We think it would
> be great for openSUSE to adapt them.
>
> Attached to this mail there's a draft with a recursive OSEP in the
> proper, proposed form, let us know what you think ;-)
>
> Note that the draft we made only proposes to use this for big changes to
> our process, not technical things like replacing sysvinit with systemd.
>
> FYI, Agustin has written on our team blog about the proposals, giving an
> overview of what's out: http://lizards.opensuse.org/?p=10230
>
> -- The openSUSE Team
>
> [1] http://blog.jospoortvliet.com/2011/09/bikeshedding-and-cls.html
Hi openSUSE team,

I appreciate such move from unstructured mess of various email threads
and discussions to something much easier to deal with and to follow!

> _____________________________________________________________________
>  OSEP: 0001
>  Title: Process proposal: openSUSE Enhancement Proposal
>  Version: 0.1
>  Last-Modified: 10 Dec 2013
>  Author: Jos Poortvliet <[hidden email]>, Antonio Larrosa <[hidden email]>
>  Status: Draft
>  Type: Process
>  Created: 02 Dec 2013
>  Post-History:
> _____________________________________________________________________
>
> Process proposal: openSUSE Enhancement Proposal
> -----------------------------------------------
>
> OSEP (_openSUSE Enhancement Proposal_) is a document providing information
> to the openSUSE community or describing a process in Factory or its
> environment. The OSEP should provide a concise specification and rationale of
> the process it's explaining.
>
> OSEPs are intended to be the primary mechanisms for proposing major new
> procedures and for documenting the design decisions that have gone into
> Factory. The OSEP author is responsible for building consensus within the
> community and documenting dissenting opinions.
>
> Because the OSEPs are maintained as text files in a versioned repository, their
> revision history is the historical record of each proposal
> footnoteref:[note_repo, https://www.github.com/TBD].
So do you want to maintain OSEPs in some github repo? Would not that be
overkill compared to wiki, which provides the same set of features you
want?

> OSEP Types
> ----------
>
> There are two kinds of OSEP:
>
> - An _Informational OSEP_ describes an issue, or provides general guidelines or
>   information to the openSUSE developers, but does not propose a new feature.
>   Informational OSEPs do not necessarily represent a community consensus or
>   recommendation, so users and implementers are free to ignore Informational
>   OSEPs or follow their advice.
What is the reason to spent a time on creating and discussing a
proposal, which will ends in informational state? Do you have any
example, where the process is worth effort, but the result is not that
important?

>    
> - A _Process OSEP_ describes a process surrounding Factory, or proposes a change
>   to a process. They may propose an implementation, but not to packages; they
>   often require community consensus; unlike Informational OSEPs, they are more
>   than recommendations, and users are typically not free to ignore them.
>   Examples include procedures, changes to the decision-making process, and
>   changes to the tools or environment used in Factory development.
>
> Submitting an OSEP
> ------------------
>
> The OSEP process begins with a new idea for openSUSE. It is highly recommended
> that a single OSEP contain a single key proposal or new idea. Small enhancements
> or patches don't need an OSEP.
>
> It's recommended that the author of an OSEP brings his/her idea to key people
> from the community to see the acceptance the idea would have before sending it
> for review. The received feedback should be introduced in the first draft
> document, so that it's as complete as possible and long open-ended discussions
> on public mailing lists are avoided.
>
> Once a draft is written in the style described below, it should be presented to
> the _opensuse-factory_ mailing list.
it MUST be presented on opensuse-$FOO mailinglist - having mandatory
OSEP not beeing discussed in a public is a no-go.

Please make sure you use the keywords as defined in RFC2119
http://www.ietf.org/rfc/rfc2119.txt

>
> OSEPs should be submitted in asciidoc format footnoteref:[asciidoc_userguide,
> http://www.methods.co.nz/asciidoc/userguide.html] with UTF-8 codification.
>
> OSEPs may include auxiliary files such as diagrams. Such files must be named
> +osep-XXXX-Y.ext+, where _XXXX_ is the OSEP number, _Y_ is a serial number
> (starting at 1), and _ext_ is replaced by the actual file extension (e.g.
> +png+).

Again, what is wrong with a wiki? Pages can be even blocked, so only
author can change them ... there can be even a template and fancy boxes
for a state. And it is not that hard to get the text form to send it to
ML.

Regards
Michal Vyskocil

> [snip]

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Michal Vyskocil-2
In reply to this post by Robert Schweikert-6
On Wed, Dec 11, 2013 at 09:09:45AM -0500, Robert Schweikert wrote:

> On 12/11/2013 06:00 AM, Antonio Larrosa wrote:
> >Hi all,
> >
> >We got lots of feedback from you all, also on the process. Many did not
> >appreciate the long and complicated emails. We discussed this in the
> >team and Tomáš Chvátal told us how Gentoo shares a nicely documented
> >change process with Python and Debian already. Essentially, they use a
> >standardized document which ensures that whenever something has to be
> >discussed, all information is there right at the start. This shortens
> >discussions, avoids bikeshedding (see [1]) and afterwards you have a
> >nice stash of proper proposals in archive.
> >
> >The proposal is essentially based off of the Python document, simplified
> >and adapted to openSUSE. It does not change how decisions are made or by
> >who, just speeds up the process, keeps the discussions clean and
> >documents their results thus avoiding future flames. We think it would
> >be great for openSUSE to adapt them.
> >
> >Attached to this mail there's a draft with a recursive OSEP in the
> >proper, proposed form, let us know what you think ;-)
> >
> >Note that the draft we made only proposes to use this for big changes to
> >our process, not technical things like replacing sysvinit with systemd.
> >
> >FYI, Agustin has written on our team blog about the proposals, giving an
> >overview of what's out: http://lizards.opensuse.org/?p=10230
> >
> >-- The openSUSE Team
> >
> >[1] http://blog.jospoortvliet.com/2011/09/bikeshedding-and-cls.html
> >
>
>
> Do we really need to discuss yet another topic that is only
> tangentially related to the things we have already started, release
> cycle, openQA, and changes to Factory?
>
> I think this can wait until some of the other basic stuff is sorted out.
Or to postpone the already running discussions and restart them in a new
process? I meant, despite my willingness, I have failed to follow all
the topics and discussions have happened at various places. So atm I
have no clue what is happening in this project.

Having something more clear from the beggining would be very valuable,
so I am for a restart as there is probably nothing more than a few
weeks, we will lose.

>
> We really do not have to discuss all the topics at the same time.

<joke>You MUST propose an OSEP about accepted number of topics discussed at
the same time ;-)</joke>

Regards
Michal Vyskocil

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Michal Hrusecky
In reply to this post by Robert Schweikert-6
Robert Schweikert -  9:09 11.12.13 wrote:
> Do we really need to discuss yet another topic that is only
> tangentially related to the things we have already started, release
> cycle, openQA, and changes to Factory?
>

This one actually makes a sense in a way, that it proposes a way so summarize
all these discussions so far so people know what happened there without reading
tons of mails ;-)

--
Michal HRUSECKY                                   SUSE LINUX, s.r.o.
openSUSE Team                                     Lihovarska 1060/12
PGP 0xFED656F6                                         19000 Praha 9
mhrusecky[at]suse.cz                                  Czech Republic
http://michal.hrusecky.net                        http://www.suse.cz
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Michal Hrusecky
In reply to this post by Michal Vyskocil-2
Michal Vyskocil - 15:10 11.12.13 wrote:
> ...
>
> So do you want to maintain OSEPs in some github repo? Would not that be
> overkill compared to wiki, which provides the same set of features you
> want?

hmmm, interesting idea, never thought about wiki as I know Gentoo does it this
way. Maybe somebody else would have some idea about the reasoning behind.
Thinking about using wiki, my first few thoughts:

- we would need to create a new namespace and limit access and check how access
  rights in wiki works - means some work, but once set up, could work
- harder/trickier submission of new OSEPs and changes
  * preparing somewhere, asking for a page/access, copy the result over vs pull
    request (which we can even link in mailing list discussion)
+ people are more familiar with wiki than with asciidoc
* asciidoc could support multiple formats for easier printing/offline/mobile
  browsing, although I don't think this is important, just a cherry on top

But I would say that this is definitely a good idea to discuss :-)

--
Michal HRUSECKY                                   SUSE LINUX, s.r.o.
openSUSE Team                                     Lihovarska 1060/12
PGP 0xFED656F6                                         19000 Praha 9
mhrusecky[at]suse.cz                                  Czech Republic
http://michal.hrusecky.net                        http://www.suse.cz
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Jos Poortvliet-2
In reply to this post by Henne Vogelsang-2
On Wednesday 11 December 2013 15:03:25 Henne Vogelsang wrote:
> Hey,
>
> On 11.12.2013 12:00, Antonio Larrosa wrote:
> > Attached to this mail there's a draft with a recursive OSEP in the
> > proper, proposed form, let us know what you think ;-)
>
> Can you please tell us a couple of real world factory examples where
> this would be useful?

Sure.

Think about things like changing the legal review process or introducing
staging projects. Or, as example, in our team, we're discussing if a package,
after having gone through a staging project, should always first go through
Devel projects or can sometimes directly go to Factory.

Note that this should be for concrete implementation proposals, not for the
high-level discussions like 'should we consider gamification features or not".

And note that this means that when we get to concrete proposals, over the
coming months, we, as openSUSE team, will then use this process to discuss the
changes we'd like to work on.



> Henne

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Jos Poortvliet-2
In reply to this post by Michal Hrusecky
On Wednesday 11 December 2013 15:56:31 Michal Hrusecky wrote:

> Michal Vyskocil - 15:10 11.12.13 wrote:
> > ...
> >
> > So do you want to maintain OSEPs in some github repo? Would not that be
> > overkill compared to wiki, which provides the same set of features you
> > want?
>
> hmmm, interesting idea, never thought about wiki as I know Gentoo does it
> this way. Maybe somebody else would have some idea about the reasoning
> behind. Thinking about using wiki, my first few thoughts:
>
> - we would need to create a new namespace and limit access and check how
> access rights in wiki works - means some work, but once set up, could work
> - harder/trickier submission of new OSEPs and changes
>   * preparing somewhere, asking for a page/access, copy the result over vs
> pull request (which we can even link in mailing list discussion)
> + people are more familiar with wiki than with asciidoc
> * asciidoc could support multiple formats for easier printing/offline/mobile
> browsing, although I don't think this is important, just a cherry on top
>
> But I would say that this is definitely a good idea to discuss :-)
Yeah, we (in Nue) noticed we hadn't thought about this either, but just
adopted what was in the Gentoo doc. Yet, as Ludwig pointed out here, most of
our policies are in the wiki, so that's the natural place for these OSEPs :D

Good suggestion, thus.

/J
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Togan Muftuoglu-3
In reply to this post by Antonio Larrosa
>>>>> In article <[hidden email]>, Antonio Larrosa <[hidden email]> writes:

    Antonio> Hi all,
    Antonio> We got lots of feedback from you all, also on the process. Many did not
    Antonio> appreciate the long and complicated emails. We discussed this in the
    Antonio> team and Tomáš Chvátal told us how Gentoo shares a nicely documented
    Antonio> change process with Python and Debian already. Essentially, they use a
    Antonio> standardized document which ensures that whenever something has to be
    Antonio> discussed, all information is there right at the start. This shortens
    Antonio> discussions, avoids bikeshedding (see [1]) and afterwards you have a
    Antonio> nice stash of proper proposals in archive.

    Antonio> The proposal is essentially based off of the Python
    Antonio> document, simplified and adapted to openSUSE. It does not
    Antonio> change how decisions are made or by who, just speeds up the
    Antonio> process, keeps the discussions clean and documents their
    Antonio> results thus avoiding future flames. We think it would be
    Antonio> great for openSUSE to adapt them.

    Antonio> Attached to this mail there's a draft with a recursive OSEP
    Antonio> in the proper, proposed form, let us know what you think
    Antonio> ;-)

Does Gentoo or from whomever else you are taking the ideas have a timing
policy of sending proposals, or RFC or what ever name you want to
give. Do they also bombard with idea after idea without letting anything
to settle down.

I started to have the feeling that the openSUSE team has a deadline or
an obligation to SUSE to achieve something or at least to show there is
tangible events within this calendar year (2013).
 

Togan
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Antonio Larrosa
In reply to this post by Michal Vyskocil-2
On 12/11/2013 03:10 PM, Michal Vyskocil wrote:
>
> I appreciate such move from unstructured mess of various email
> threads and discussions to something much easier to deal with and
> to follow!

Thanks.

>>
>> Because the OSEPs are maintained as text files in a versioned
>> repository, their revision history is the historical record of
>> each proposal footnoteref:[note_repo,
>> https://www.github.com/TBD].
>
> So do you want to maintain OSEPs in some github repo? Would not
> that be overkill compared to wiki, which provides the same set of
> features you want?
>

Yes, I think you're right. As long as proper access permissions work
in the wiki and if nobody says anything against this idea in the
following days, I'm changing that into the OSEP (I'll have a look first
just to check how permissions work there and if they're good enough for
our needs).

>> OSEP Types ----------
>>
>> There are two kinds of OSEP:
>>
>> - An _Informational OSEP_ describes an issue, or provides
>> general guidelines or information to the openSUSE developers, but
>> does not propose a new feature. Informational OSEPs do not
>> necessarily represent a community consensus or recommendation, so
>> users and implementers are free to ignore Informational OSEPs or
>> follow their advice.
>
> What is the reason to spent a time on creating and discussing a
> proposal, which will ends in informational state? Do you have any
> example, where the process is worth effort, but the result is not
> that important?

Think something like: http://www.gentoo.org/proj/en/glep/glep-0057.html
It's mainly a series of definitions so that other GLEPs can use those
concepts.

>>
>> Once a draft is written in the style described below, it should
>> be presented to the _opensuse-factory_ mailing list.
>
> it MUST be presented on opensuse-$FOO mailinglist - having
> mandatory OSEP not beeing discussed in a public is a no-go.

Completely correct. I think I originally wrote there "it should be
presented to the opensuse-factory or opensuse-project mailing lists",
then changed it to just opensuse-factory to have just one entry point
for OSEPs, but in any case, you're right it MUST say MUST.

I won't send again the fixed OSEP-0001 in order not to spam the list
(at least, not for a few days so that we can collect more fixes), but
consider your changes included.

Greetings,

--
Antonio Larrosa
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Rajko M.
In reply to this post by Michal Vyskocil-2
On Wed, 11 Dec 2013 15:10:34 +0100
Michal Vyskocil <[hidden email]> wrote:

> Again, what is wrong with a wiki? Pages can be even blocked, so only
> author can change them ... there can be even a template and fancy
> boxes for a state. And it is not that hard to get the text form to
> send it to ML.

If it is used <pre> OSEP Text </pre> then even text format will be
preserved with copy-paste to email.

--
Regards, Rajko.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Agustin Benito Bethencourt
In reply to this post by Togan Muftuoglu-3
Hi,

> Does Gentoo or from whomever else you are taking the ideas have a timing
> policy of sending proposals, or RFC or what ever name you want to
> give. Do they also bombard with idea after idea without letting anything
> to settle down.
>
> I started to have the feeling that the openSUSE team has a deadline or
> an obligation to SUSE to achieve something or at least to show there is
> tangible events within this calendar year (2013).

We always have time pressures. Many think that a Release cycle is nothing but
that :-)

Sending the "contents" of the proposal before Christmas is something I am
specially interested on. Christmas is a good time for "processing".

In general, you can see the plan here:
http://lizards.opensuse.org/author/calumma/

In this discussion process we have received several additional requests of
information. There is one that we are preparing today which is to provide some
explanations about the target and goals of the development version proposal,
Factory. We are also finishing the mail about time and effort.

Saludos
--
Agustin Benito Bethencourt
openSUSE Team Lead at SUSE
[hidden email]

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Michal Hrusecky
In reply to this post by Michal Hrusecky
Michal Hrusecky - 15:56 11.12.13 wrote:

> Michal Vyskocil - 15:10 11.12.13 wrote:
> > ...
> >
> > So do you want to maintain OSEPs in some github repo? Would not that be
> > overkill compared to wiki, which provides the same set of features you
> > want?
>
> hmmm, interesting idea, never thought about wiki as I know Gentoo does it this
> way. Maybe somebody else would have some idea about the reasoning behind.
> Thinking about using wiki, my first few thoughts:
>
> - we would need to create a new namespace and limit access and check how access
>   rights in wiki works - means some work, but once set up, could work
> - harder/trickier submission of new OSEPs and changes
>   * preparing somewhere, asking for a page/access, copy the result over vs pull
>     request (which we can even link in mailing list discussion)
> + people are more familiar with wiki than with asciidoc
> * asciidoc could support multiple formats for easier printing/offline/mobile
>   browsing, although I don't think this is important, just a cherry on top
>
> But I would say that this is definitely a good idea to discuss :-)
 
So, let's make cons & pros list, or wiki vs github list. Wiki is good for
collaborative documentation, but for something like RFC, we probably want
something less changeable, but that could be arranged in the wiki as well
probably...

Wiki:
   Pros:
      * people know how to write there
      * we have it already
   Cons:
      * we would have to setup some rights system and test it
      * hard merging and discussion of changes
      * not easy to prepare full OSEP, review it and merge it

Github:
   Pros:
      * easy way to merge and review changes
      * easy way to submit new OSEP
      * rights management for free
      * we can accept only full proposals
   Cons:
      * not everybody knows asciidoc
      * yet another place for documentation although little promotion could
        cover that

What did I missed?

--
Michal HRUSECKY                                   SUSE LINUX, s.r.o.
openSUSE Team                                     Lihovarska 1060/12
PGP 0xFED656F6                                         19000 Praha 9
mhrusecky[at]suse.cz                                  Czech Republic
http://michal.hrusecky.net                        http://www.suse.cz
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Henne Vogelsang-2
In reply to this post by Michal Hrusecky
Hey,

On 11.12.2013 15:56, Michal Hrusecky wrote:

> Michal Vyskocil - 15:10 11.12.13 wrote:
>>
>> So do you want to maintain OSEPs in some github repo? Would not that be
>> overkill compared to wiki, which provides the same set of features you
>> want?
>
> hmmm, interesting idea, never thought about wiki as I know Gentoo does it this
> way. Maybe somebody else would have some idea about the reasoning behind.
> Thinking about using wiki, my first few thoughts:
>
> - we would need to create a new namespace and limit access and check how access
>   rights in wiki works - means some work, but once set up, could work

I don't see why you would need a new namespace. You can simply have a
decent site template with categorization in openSUSE: and a Portal to
tie it all together.

> - harder/trickier submission of new OSEPs and changes
>   * preparing somewhere, asking for a page/access, copy the result over vs pull
>     request (which we can even link in mailing list discussion)

Hm why would you need access rights at all? I could just start
openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the
"key people" and if they like it, propose it to the mailing list. Once
it's discussed, you can reference the discussion and change the category
to Accpeted_OSEPs etc. etc. No need for access rights....

Henne

--
Henne Vogelsang
http://www.opensuse.org
Everybody has a plan, until they get hit.
        - Mike Tyson
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Michal Hrusecky
Henne Vogelsang - 13:25 12.12.13 wrote:

> Hey,
>
> On 11.12.2013 15:56, Michal Hrusecky wrote:
> > Michal Vyskocil - 15:10 11.12.13 wrote:
> >>
> >> So do you want to maintain OSEPs in some github repo? Would not that be
> >> overkill compared to wiki, which provides the same set of features you
> >> want?
> >
> > hmmm, interesting idea, never thought about wiki as I know Gentoo does it this
> > way. Maybe somebody else would have some idea about the reasoning behind.
> > Thinking about using wiki, my first few thoughts:
> >
> > - we would need to create a new namespace and limit access and check how access
> >   rights in wiki works - means some work, but once set up, could work
>
> I don't see why you would need a new namespace. You can simply have a
> decent site template with categorization in openSUSE: and a Portal to
> tie it all together.

hmm, to make it findable and reachable and not that messy?
 
> > - harder/trickier submission of new OSEPs and changes
> >   * preparing somewhere, asking for a page/access, copy the result over vs pull
> >     request (which we can even link in mailing list discussion)
>
> Hm why would you need access rights at all? I could just start
> openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the
> "key people" and if they like it, propose it to the mailing list. Once
> it's discussed, you can reference the discussion and change the category
> to Accpeted_OSEPs etc. etc. No need for access rights....

To ensure nobody randomly messes up with it without prior agreement on mailing
list and to make sure all changes are agreed upon and discussion leading to it
is documented. What would prevent me from putting document saying that
everybody needs to wear pink hat's into that category? It wouldn't pass the
review probably, but apart from that?

--
Michal HRUSECKY                                   SUSE LINUX, s.r.o.
openSUSE Team                                     Lihovarska 1060/12
PGP 0xFED656F6                                         19000 Praha 9
mhrusecky[at]suse.cz                                  Czech Republic
http://michal.hrusecky.net                        http://www.suse.cz
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Antonio Larrosa
In reply to this post by Henne Vogelsang-2
On 12/12/2013 01:25 PM, Henne Vogelsang wrote:
> Hm why would you need access rights at all? I could just start
> openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the
> "key people" and if they like it, propose it to the mailing list. Once
> it's discussed, you can reference the discussion and change the category
> to Accpeted_OSEPs etc. etc. No need for access rights....
>

Well, you for sure don't want someone to be able to modify an accepted
OSEP with something different than what was accepted, right?
Even if it's possible to look in the page history and revert the change,
it's better if those problems can be prevented before happening
(less work => more happiness :) )

--
Antonio Larrosa
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Robert Schweikert-6
In reply to this post by Michal Hrusecky
On 12/12/2013 07:55 AM, Michal Hrusecky wrote:

> Henne Vogelsang - 13:25 12.12.13 wrote:
>> Hey,
>>
>> On 11.12.2013 15:56, Michal Hrusecky wrote:
>>> Michal Vyskocil - 15:10 11.12.13 wrote:
>>>>
>>>> So do you want to maintain OSEPs in some github repo? Would not that be
>>>> overkill compared to wiki, which provides the same set of features you
>>>> want?
>>>
>>> hmmm, interesting idea, never thought about wiki as I know Gentoo does it this
>>> way. Maybe somebody else would have some idea about the reasoning behind.
>>> Thinking about using wiki, my first few thoughts:
>>>
>>> - we would need to create a new namespace and limit access and check how access
>>>    rights in wiki works - means some work, but once set up, could work
>>
>> I don't see why you would need a new namespace. You can simply have a
>> decent site template with categorization in openSUSE: and a Portal to
>> tie it all together.
>
> hmm, to make it findable and reachable and not that messy?
>
>>> - harder/trickier submission of new OSEPs and changes
>>>    * preparing somewhere, asking for a page/access, copy the result over vs pull
>>>      request (which we can even link in mailing list discussion)
>>
>> Hm why would you need access rights at all? I could just start
>> openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the
>> "key people" and if they like it, propose it to the mailing list. Once
>> it's discussed, you can reference the discussion and change the category
>> to Accpeted_OSEPs etc. etc. No need for access rights....
>
> To ensure nobody randomly messes up with it without prior agreement on mailing
> list and to make sure all changes are agreed upon and discussion leading to it
> is documented. What would prevent me from putting document saying that
> everybody needs to wear pink hat's into that category? It wouldn't pass the
> review probably, but apart from that?

Makes me wonder why we do not have a million wiki pages that require
everyone to wear pink hats.

Do we really have such a big trust problem as you are displaying here?
If that is the case we have other issues to discuss that would, IMHO,
take precedence over everything else.

The wiki is open, enables easy collaboration and has a history, thus it
is still easy to see who made the changes. And the person that added the
pink hats requirement can be asked why that would be a potentially good
idea.

Later,
Robert
>


--
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
Public Cloud Architect
[hidden email]
[hidden email]
781-464-8147
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Robert Schweikert-6
In reply to this post by Antonio Larrosa
On 12/12/2013 08:04 AM, Antonio Larrosa wrote:

> On 12/12/2013 01:25 PM, Henne Vogelsang wrote:
>> Hm why would you need access rights at all? I could just start
>> openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the
>> "key people" and if they like it, propose it to the mailing list. Once
>> it's discussed, you can reference the discussion and change the category
>> to Accpeted_OSEPs etc. etc. No need for access rights....
>>
>
> Well, you for sure don't want someone to be able to modify an accepted
> OSEP with something different than what was accepted, right?
> Even if it's possible to look in the page history and revert the change,
> it's better if those problems can be prevented before happening
> (less work => more happiness :) )
>
  more mistrust -> more FUD -> the dark side

Come on people, really that's your argument. We are, at least I hope
not, not in a community where people are after each other. If that's
what we are becoming with all of this then we will not be a viable
community for long.

Later,
Robert

--
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
Public Cloud Architect
[hidden email]
[hidden email]
781-464-8147
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Policies, or why it's good to know how to change things

Michal Hrusecky
In reply to this post by Robert Schweikert-6
Robert Schweikert -  8:14 12.12.13 wrote:
> ...
>
> The wiki is open, enables easy collaboration and has a history, thus
> it is still easy to see who made the changes. And the person that
> added the pink hats requirement can be asked why that would be a
> potentially good idea.
>

The point of OSEP is to document the agreement, not to collaborate on document
easily. And be the source of trusted information. All changes should be
discussed. Not that somebody switches blue hats for pink hats and after new
ambassador creates tons of pink hats he will find out, that somebody just
though that blue meant pink and pink was nicer formulation.

--
Michal HRUSECKY                                   SUSE LINUX, s.r.o.
openSUSE Team                                     Lihovarska 1060/12
PGP 0xFED656F6                                         19000 Praha 9
mhrusecky[at]suse.cz                                  Czech Republic
http://michal.hrusecky.net                        http://www.suse.cz
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12