From e8f5c9cb43f1ebc9236eabec576e0bfd6516867c Mon Sep 17 00:00:00 2001 From: adrinjalali Date: Thu, 13 Feb 2020 14:14:32 +0100 Subject: [PATCH 01/15] slep000, slep workflow --- slep013/pep-0001-process_flow.png | Bin 0 -> 12925 bytes slep013/proposal.rst | 270 ++++++++++++++++++++++++++++++ 2 files changed, 270 insertions(+) create mode 100644 slep013/pep-0001-process_flow.png create mode 100644 slep013/proposal.rst diff --git a/slep013/pep-0001-process_flow.png b/slep013/pep-0001-process_flow.png new file mode 100644 index 0000000000000000000000000000000000000000..0fc8176d242edf8163a1436adcd4afcef5d97802 GIT binary patch literal 12925 zcmajG2T)UA^e&o&8hS6Gg&w6>L3)4?lpWA ziy*y7lOk36&F}y2oA+kkoq3s)oU9~kXYZ49*80A0tt8wt(xat{Rfo98=BHSo@j%;kWYMxyQ2T@KvpkNF5-)ve!7qS?t41= z1={*J00IL8C7nH7eeG<$93(w`oN{(lApigrps%C#ASib`FL=gs^s;;2IR6h5j)4gt zuQqb8E(Xe?F*YauFyy}ZTl2RM-r>t0ICHs+*Rg|{?taj6OJ+zAhMY4o-4zlz7hwtx z3r7!ZtNE@Cob~tT1^+$|YyGVtx0V~So0X-q7Sh&t$}3IN_5Z)QM8t9*%|>jC4KoUg z7Jxj3XA{JKwwkIvIB#7VrC-PSiP8YdK?hXIh5jjL5d>>Y!;5X42~#uB6QqG`7JTxP zxe?T2_OhI7k6c=HBW2}#b%bF=4EUsEZi70PT-CHktBI775K53r+`yU0k^{R%XA@K# z*_Bi_jK-AD0o@|A2_R+aApZYM!57LE4=Y1#IbvId?w#=zBR$Pk>=(Ud4RnX zynuTTIjdSJycoT>r0Kx#J`8VeE)onK8q4{MWPm~J5|LY!;)5e?Vnb}1X=R2KlOB>E zZ))ctY(fuJq`sFFsA0Y;pJgN~!dCk_xz|v7KToP(e9pk-c-Zs0w&{Sr^uQHzK8C#r zTks$_qB71z&N}!CRYUpK^Nq=N0KDQ|3P}&n1eqt)2(vx*dwDeO^xAEhQ-Yg3gEgb` zDA$L0>v$jd2SC0K1gxs0kr;wM5<|9@P3MNWP#T?G zw%S$Q#szOtPrmtD6?U09_|H{HN!>SfSr*McK9KR?;$)C0f7P%t7!SX6O!ZoX+Mg5vI(*(GAmt@bDKi;J)G+;rhhW~O{yv6 zFRY>bH6%q@c#1m=!5Z23E*QZLX}CuR%#$ZuLj(<;#y%dEzO6}=kfjGuM8LP_389Ms z@EZi?E>+14*UgeD4`~!1uScG#abB_+Glvbhbn&?suRy4u3y6JmVWI<>0OCl|NS&xbtgO$Ums*1gT|g^ySS? z@5Q&smSa@pQo||apJ?TY1c6y7hu%%-?{&`m2esrc6O1utLz+YR_qqU$+(CRwz>}k)9=Sk28w!aGlkpCW%)MAxg1y6ob zT(U`(%(u!kRVlpaKrwkUF}-vucB{9GaI(xHygs^L8jJ_FrON-{B$U1SpDhOZcc1@GBe48s+HidJeCert2^tXU)UG{$ z0$Z367*wVSJ!xxS&_9ghz5~-dYhHU@oBNIng7MY$a*s1$^R6B6#}f9kUXVX8n4I<9 z<(}NHW`DhnXLKIBYAW7Rn}E(+x2smM-i!Zc>hZkjiuAot>LAu8DQsTfi-~DPJ)HmZ z_0ms(VVGmfN!n20l^PsaL-|wLXNGy_C$kLjB}YVZ^Zn8bk(ysmR0LI&3G#<_lc1+q z66Ie2^BWn(5dn55jVxI~ZGbr~$0{@$N!z1ZOL@wKW`kBQ{Ey3wvhtm3Xm>wga6K2?Fmy!y&z!-;7@wq%W@}}!%L+o%2!Z! z7vDfQaw_4Td>Y+0n5Un|=_DX&>JlmhaQZr?`y~F#No5tqo-4NVyspu19*D$P#)t%r zyB)W3l4-HPEp56$_BH#;jJg-@kkK}kN_fTZiif}&+8SoPN#GX=S?<_BgY<$F8*cL2 z=lqFZD#^J1_{h7qNH2z60H%>tt$)DPBW9_U%obGVm`;n)(*o``986HDrhO7D z7@FeHGgd2Aqu^wIE<={JL=J7&lbq1{T{78Pqc&SRzsuV5n`c#59_wLr922WGtGOUk zjh0|RWDnkc<+9{JCD$?z@jfy0gZnTr85x7xb*|H1_3V2q)~Q@wrJ5&<9#3({m>co8 ze~peSnd)ThQCA1g&NLlI-7-~Xis{c!CXe+5gbTDk2}&oRk8W>tk{q_AXoKu{gjB6{ zA{bP3rq80rj(T2uS(O^n<2N~k_A&$ubOw}S5`ZMX?SSTHYN|HW;4_woH;(imoI!vl)AS=_ZyPS?45X#)4+TtPH` z;5!Vm6M!FB4%^LqhtZ3e7j!y=$@hfE!xgnoI_ZZOE=5KR^h&_rRZ8dCcLnbMdbg83 zI#d|0SZUtz0V$WSy$SDhh6#mYRj%8I&2g24aD4^$ya>|YEGvXix>MQw-U|iJhXzvi ze;;qWQYdtwkcf0)gU${ayr(x^4392734{IlTh$*|zNb#bPV4xVw&yR`Q~%rqE%ns&oW~kFqkPzyRGk=Qw_a?L6 zn4dYAP!1b%Digcr$ihdGRfpY6l@JnVl#8$q-hExP9@{Wfpe$){@-)yOH*KG`G~$9I z%P=4DyE=I|dGXwYmtS3LUKv&2Oq-aC+>cYFDUnAF=a42{KQ<)rOkY#+#tbH_LkQQZTX|1;#<_bv_;GSGGt(w2`it$TKIXMe1hh)r2r zJYSYqJTPn`?eSS)IN5WC`riCgzw&xTT4|6RcHmM)YPUTc*N+eMzAHLECZYd{TR2rk zej|nB#)iq;ykMAv;fGP6gPq5YWS+iHh_K{HR{y!ApUw^K+uz2%4u8!P%Vt$bVUD-H z^FPB>gZQ&N^fvKSUOfXkhQe(q#PDFSs^q9|KyDHsyhoi>R zcu3$z8DJy&I2iEwwb#54@$EY`GK-3|!+=7cPl~6fJ{BxxEYJ{U53Xk3Y0YjT93J6L z3J4$tr`_2DPrq!ef|UU{6X8MLgW7k4Jc#aSgG+vHoVAPzY7Mern&w$+KJorFIB~lR7qwGcs$#lE zqw|YC2O#r55tNY$N&$3ww9vd;6#8Q;(bNOR%E~5T5=45znwjY*x|z$UA4sUUGv}R3 zaH|6~mVzcjV{daai*r@mav%+G)EFa1Lab)WFw50Qp&qP1^(QZcYF2PK}_@655 z*)24n%BtJzD-`ZL85T}3;#AOTQ_0MTG#<)MYbFvA=bzk4WRGKyqdW~W2d>QVvkqlX z683?iPZzvjM3j~78hw8PxF8RL63<8Sy{GA#0R_ZkrQc6sYHkD%DSl6Ts2ki7M)T*j zrZu9ajRnFfOW9ZI#)06?BsW!`0}YVuP|)cF`!pA!ZTSR7`x=Hly=Nz`CQ6M^M~`y=Csxuf2|Je}~%KdS?$ ze5LNEZtM9@{0AeN>1im{kGXz|bTe(p zVClX+XqwjD;J$e1%)w{msUd9kkPi6|kff8{yGmd~)n9|XUbs@+v2G(R>r0j8aOPc> zJ1pb!qCG=j-b;TJzJOk;i^9&XXn;fwE)Eip(X zk7Rk=^6;1C-{PS%NiM6_y*3aIdAPNQ~^f zsk(Sv?N%)IOL!yzG;J@=uHoJ7x&F#wRFhl~IDrXkp*@aX7K7|vPp+(^ z&+ET1vO;eO_&#`pY>`AZ&Mv$%6q=($3;)GE{ea8zWT29#jD9IqCz_>k*oW zmha|iZJr~P>>O#}0JNLUz`>?Tv%+1e3fC7S_vL}?OjqAJva{)D&uj0AOo%K{o1Mgj zgx9?D^x5|Az6I24IZ$lc!vC!bjo&g(+p@k@?csT%oISI)xjjy+Y3_G&SUnAsYt>gE zn@xzk_3xG)vIx5G1)Ux2P-{TU9 zt89NPb9jVV1J&h3-mvG#{_zjqN8LqFu2pvAcr-ZxdryThbAAP<3Y`id3PFiykZcCE z)V6~0xw<#a2kNn5IbW@2!-qoyZk=7N1^E{gg?z10<-rx+^0`M1L4LxM%xOj~tDx8# z{Ywq`jSgWE@Lo#83FcK05P{q33G>*EgH z(rO-ZT^nGeJ^2yWiq%wN459*8klEk*z}b|QD&k-1^&FO*`NbTudWAKT;uvwdLk>{)g?VjK;*vL&EVS^cZ zrML$N-y(WWZ%Ood2Np(LNkxm)Z)1Z!+uli~-oy8EQnzQeR+?3Rf2>-CiA?s)O;AKFFD zb|#MVO+6EBAZLw(gT{b#J&Y)B$ych)Iyd6W3hO`l08K{rYd_!iv|f zkl_QmBp(I^35r#oT>NXNd9b(N*BUs_Am|-vWF^>HL$74;EM{vS6u84K(A|c(2n@h) z4eG*7H_0bYWRUlc0}7ltWsL`PLH49fk#G15I?8&|PoPvdcWO(`Z7}vU^Vs%*vV<~~ z7~fLy$E4o-1F-i;LucvcC34vYj}y;(N3$+E2Q65BlgK3bk(Ve4*C8xy!aK*e5T~4x z^7B{gZBrB}vx#8u;N;D^*~l9qy5p9m{znxt7Ui5R;Re{G_(NMZV6-8cA% z90|wjsv66&1|^yOdx7@C47P}@k2HdL!YmD%vd+zgoZgefgzSV)61bW!l9#*xa@%P2 zKPhqpP4UlnBo7uj0ed+pPW@^X*g3SJTzWO*nfwWluR4T~5uPF-|j0RfzKy*CBXJGFF;9NRf-54L3#ZAbfNJpSwx& z42Ks>m@m>LR%NCAjo&O5V?tlTB(*Uns-r_5x%Y{hr?3prROvOgt)y^RR*B{xt$DIK zN14(T-`C?w(1)SonQxY~@8ao7cQl{8Gtgo5Y9+eJJ-!o>CQJn0jQc|7nn5=qN#V)I zRn@F*aAzkU;fePm^4@6{)E(h1GlXQnD@r8-EXu4G0U|S?)iLu3 zAE$AuyU5wi#z!0^7qI_?Ta_ZWSu$Ib$FaEHmY(+`tf!1~2K6dr!?YjZgSXi8Y~`u{ z!~4A)oe!V|rWTdMTtnf_{6y$;6hRyrxeD&gyzFHFZf?B}~Dxze)F|I1|SiFc8w5Gi(+l8=-X{a8PF`5g?)>Yd5l7B7}6oyn=z= z0YswNZ&3d3sLv2c;D_KD-CI^flrFXzQHQjzjvK5z>Kk5078J*M$Li`2VTI= zTuibC=DCz|N2sx^F!0JgQ$a)a`rQk~LF+=@!dE{j-SieTSR0Lef96x6hD0FJ!5OEx1rmH3-VSGuN_#diJ`kGU1UuVNznN*# zFVE10QWh@>>k67gP{Yi0daKEd5WxfApg>@`xdX`s-h>dYi)bs@0D;BaHY!jp|2o%E&eO;BpdHN(|6>vl_>*G2 z=WATx3kK(>Y1ko%9&74$-Y|QsiNWmiD#>~2PRXj!LDlJe%}sh+mVu7aIW$6+27q|A z`1wOb>+sx6UFQ`FJMcPhDAPONY=Vkov3KyWm!hc#B{afWh1RHc%N9HTU^c;7)?E-~ zdO`7Cz`wiKs0Y1XD=GbAOfx|db^hxKDhGo)$J{mHXsYgz7wD*s_j(r*Mu7N9DFkiv z1{AEC?>mVmQf^8!XW)b^fWL_K0mnUwB~erTVX`cr;;1KgS13>umn_*u*EF;r%|hH$ zv?1Sj1-q>b(M#VQkPKwvT1CxUf}@W_G6Y6n4XT#n&|PA`xYlC~jE3dMs%R$-%sy zJ#e(2uL^KlcteqlvX<~v<8nHcj+1YV(t9Q>HM>g;6hc?w1sYG@jV{XG5#1Jf^lci~=& zXt)o_QsAnkR?JnZh-MPJF=>eVBhX9D3zi+sTKm_u9L8D_)OM$t1T4+$4mwuKuDkyB zN{VbwH1~Av*=%NwW=>E2;=qz?43p=oMl8V-7+7Ls^1 z`A*iEd@nk7{^j{vu2JI0-A}}~UzW;wu@?nAHYPPeY6$0kZBInIonBd4yu6y-Udh+! z_nDd4F{c(-RneWho>Zgn_o%`6 zc-VtK8jco##&_@BvKD)w5PvF>;^uOUpA2xLwYm=|2)CjwG?R$(+{J;&U{n- z7Ev>&bcvPc^bnom`X!B`4uQ5>?)ZC{1=0#xIg_3+vXGUh&YYrjm~jnjFrM_24dX?ts zOp!T*4`%IT&1u$0!T+MRx=it5E8dd>ld;oK{=*xxMYB=gMne)()%$czAV?XZ8=8+w zq`vcJ@x2(<+|F^BD9qWjm4A05T@$0j_X0OXShJE{vpr+@F#swC3B@~EYyAEhhs)zM zn~xUou91lk0*-Kk+uFZ!GgE%DNhTm!#z!PaJVM?YW5%Mu?<`3{rB*lYV8%>YCUlnE zBM~>>6q0#tW5b^*XRlg<(Xj^dUuAhKr;~dMyrm&Dm!$!r*r~O$o=;DQb@+{x{&iPr z)yfsr4ZF$25ASa0zc4gwy&*dv_WFSw!U9g=CQa!X*>)>D6lfp#7J_(s?=Hx`IfNst ziDUbrG^WaXR@bMh{ja-EQ7(w{%6+!Il_@_PwKfOfdZ z`#wtTU?;(L9hrBvPJ%x+e3saeWa!`dwh3D1Y)yHC^)TzP%BnuW7Ne z9{xI`weo>-Q0||TT*fF}+dA%Vf_l4M4?JY1+!m}+S~d(JSMuie91V&>>{?^J!^+b? zbVN#R?TxuPbOd#IRtt)?j$uA3j4H=Z0073F|9Sy(=QY*SLIqai)|4c{w~OsDtWR_% zI+b#$eq&v35D{f|ALU8|rNEmiZMh~c{i6myZQGiue$+_`@cfw#tf(9=mzP21Lv zU=7_)f#({Ruf}?0!uc1!!XWRy^R!1wH}|JD-~N_&?us8M2Y;ZgsE>)JMfQx3eEDcz z{BbjnjW5PQsN0~F@iVUI$_chFCM{~HOIB8H_XJkGw5NifmCPE$mkc2?;k}1(;g5T6!dNMW%{&LSQzfPlK6aZHi+#){|^d` z8p&i)O_NW0CQbWA+MJF$etv08x;K&tX^9Y#OZc;;sF`*bjEty)m#hwv3y1Y*@bydI ziOu@BnJV!;@BI)=$|7Uq^E(qr=D5S{cH2@LP-)vgQiq{rk6W$}^1;HYW-1E?>91Wa z%mO5-USHKjPs$`Y+Ep6Rl$>RzvZ31IWLc$<^(wK9|Ka%x^=~DY#@R!OhXyUTA&BqN zqRqB=8eX``V?&tS->&Zg-4ztXwIKQywD1&nqe3K=s&Td~i9}BnCmN%;3tH{S&bP5n zy4^tUw>#GT{lzg+MkbpN+CB+wc1awpz|?G@>Pq2()Xt_L56g zY#&e%S>XRjz{D@+h&5sPKUWQibN{~^MFNQ|AW>y)>WX9Gr=!(@jtxp~(3T^?j@U!u z5QdqE{lj$s*7P_J%l%tS+cT5E_2~LYp7n80>fFfV$@qQ2g|Vd;8UiOl|A%UvtxyV> zp(G=iex2kG=M7I%I&c4|XDKSAj~98xB0dpXtS<8j8WB5X+f}xBaW~;+lfKWSXfm4k z^b>6hDdYIcE$|@%1j5I~W~I@TP!i`j4i8!A1EoFzUa*%E2$m<$x%WN=CLf0pQ9{Ojf+Pi$ zue0$pj)aRO955GHO;19sO#PKOnNmL)kRd$XLR7omUjQu725w`bu)Cr?(;@itT;>SA z=3N^_uhy0}+w`P?b&+{kxrdrrgH`_8=F;?uxZz|H#8GJvA7Uk1eg$1({`WLtrzp9# zCI|Bd^TBeq;d67J<+T+_hU@-{gA+`hdpoPx>^gC)vXENceq18*UUH8hzeew zF`UMO)HN#?M4@SO-8+q^rD4@jpem#b#>5OoG&KTg8w&&u#yC-!xPH(I%8&lkvEo+5 z-QlZ+1I%b^^EJS_@ivkj3Z;0?{4u!yNTjd>tvWRRYCAf*E6=J$5oMFF3wu97W~BuZ zHo~A+)qP!83jR>y{V%QiT!}O*`}}iF+YWbkh(jt=3qN*5aoFw-3R|i>Cxn&{?_?M5 zhR}NHt{f0699MdEnI8wVZZ(S;3v9s~~g3Qv;UIP%^b zRUSgk^MUYeqx*7aQ_=mV)HCO=F>#pLR>i29H6@;)?pHrZ!cw9ia~lK0Pv)co2L%PU zMSzpV@gFe_Gp8p24_y!n;H9wVTFPU{pQLzTXb!lG;R~7MUYp)cv9&K`0FFSm6{KfE z!ue|W*j4^jBf{Gvh{}||HpQ-gRLDGpHi@r<^VG~LhZDI++Lruu);n$X{Co74;#mpj zu~2q5jp-$S;ggF+)Phx1GzXG;FAGDyrS#1S<{8ufwYHN_W#p77iwj8K*9-RnH^#%of5_9}p42p{WTc(* zVQ+KefzBxt7{`zLWDkWAThdOcOIHn2lqaOA%I^W0zI>&q*0|{&NbItE1Qp%8HAI7U zDGjT6=L*#T?%#x2QAW#@B3zuUKHrd z0zWsF4`T1tM+!EwI0Gk}4%qhRn;3O9@)P?#mvPKjH8k5Kwc{+N3b*HT9XJwXXq0CL z5-Y|0_={{;?v}?y1Gk4E*t%z%=1t92GXAtxs%dsAN}eAXs%t}ZHn58qAF$TH8CK!| z4yW5Ibj&kltWNpj&T3RGe^$SSJ*Am0%-M?Qbw|v1}$aSe`qr9Wdmo*lPESH&ax6#X{xe8>7 z+)+q+3WcPMPUwhsb#gD$kA@8P^4pOAoyUj;P1t{W60sC&@}Mt_D1_0g6t_wwt-$VLvb*+02aaw;?7u);Wr>*Tg=~E=n1`|0`v#GC^}n-WPS) zv70@5yQNTgnNt9mBdZc04(|K$0~M%DELj(cLDJfulplB|)q{8+l^>X~5}msL$4ORJ zOB`@T<~H7cz!z0N=1!(+cy=`~euv(sgqWW>{QFafG7pt(Bm18<@-`}!f2O^Y(;gr< z@Ki4S7sWnxXWrC=-plL9>CFpX3zY(cAwnan$L<~!v|SZqvBl`Ht)jonp9BVLx&Atz zt~I)T=Dt6<1Z$vQk+FFnVi`kzb%|SOPFpHFjE#=`E=?oIR}U|L_afqJdUrpbCOMEV zeR1ZY9+T1G8;k~Uc9{2v`t0y;wStn;q+Nh$$dL;4s8*_(5yU)oY?Z@|xh|G4Vh1+x zZ+EZ3S5kk{1aWM)^F)iJXkWe3CTe`|Fa=G`^)TkYev|EkGfoNA5^5yiriUosg4v}u zA_Tel?OrA2A(Dd;EP`+mn(bAZ=IQ?GpWoX&S z8OaG`L3M#mh(QwQK|wCKxZqhj%9k~ouX&zhdAHGZwgH#rF3x0g?RAL)>;S@2(UR<- zYv2ITBN5%kC)j+I0cby!mj%>H5ijuQ~8K!2ObE#!BbquQ&AB5=jCNrFj?5_L-~y@R|ki zFwv-6H#K(&uFeaGiGG`J+|QdmKPIRyu;NQB2xL{WVk`sDk(hK_JSpNn=k{l*v+K)| z)?EymzX35#>$Uw2tFHKdxiyT|S;pk7aXGZ_J890y14Ee9%Lgymu$v^xY{Y6(kb^6xy*Z%GCSf@Q8CkHKLLJ0?`Eyw64Oqh9#jm&p zhtl#h?l}2GM%;dT5#Nc*&gG8gtx1ojNy)Q0>7-tnF}3;Se6zw&I$#ptrcHdCd~0VvlX@$hX_b4&mdbg zH$AhL(JIhwTa>}mt<2@MlBcZ8L2Bi0AvQM_X}&or@4xwXnG12Q<;bd`>8eoe!XEFc zH0&alzeYqef4hRcba@W04yDi5q!W=hqeXx=d8=oStHOt6807V5@zJ3-!TMmV5iCja z-d1ztTG$s+SLzGismENExo_+%u7&o)!ZLinj{9rL%z3XBydWioF#znpCCa8gQ1~gG zv_H!Cdwr9b-sIxyo34k z;@BX3xYc?o-xF@M@$7LT8fx*F~wk}k#A=|xiJHcznU^AN+rh&cENx3v6b2=O8#i^s1foS!S%AV3T z!xZ1D(vPqHoIpEdGJ_5tdTq~E6eW$mVu5}b{&UHRukNZtwUV#*edhf7@EZ2}rzZ|F z%+d{8AvqN*(ibnJuB3batPu=O6+=$WJa3^uN?daPQ*M?a8Q@n)|L<_s3T8LX>T&pN zX(0G*8BjMGivF(4+6#kGnvudbY&8M@+-nwdJ{A8a3hej(?e6NQ0)A1I!QbBOb?Zw0jy`T!xlJ{2iSv=IpwQB3y~w`SvsFkBNcYP+=&mPh_gL3A07xftCI` z;b!dlFg;o}TUa&O1K&nahxG@FoPAy^Jc6Z}RLs}IZf}h{TFy%+b%Gz|%)c%QlQEw` zQ|@bhj{NrKU?}LXP&R5eVFE?Ul|36}V7)6Cciv6VS3dK(WxF)F?gJS5=L6dllXo=K zWXsvc`a42v#vafTgTE&hl3!2$4^)YwXTBB|*CY8mg@hL*!9(ZaFQ`M`95R2QPIDci zKcnvS=jJQnSj%Y*NJ9p`rI^vK;M6@WQVCF^YC0czx@);oNd511h&si;2$lH;TsHT3 z3Nf?seHgNr{B`!u6`SgNSN{9C0@a=}>*e6@2jMc{GC4Nf4N(>atsa^R8eTa5*wYmDs2BBKKTF6 zqeP1Nf1r{*PW+1r4{UkQZkGs}OSp1K;8Z9BSruLuQB3odL5oix6~B);-jIIjBvWQA x=gy&D3#?RLPFl%~aewagAM5=8ZeRaiM}_3Kbo=sG5dSIy(APE6se;=?{xA9@T)zMS literal 0 HcmV?d00001 diff --git a/slep013/proposal.rst b/slep013/proposal.rst new file mode 100644 index 0000000..5457ef6 --- /dev/null +++ b/slep013/proposal.rst @@ -0,0 +1,270 @@ +.. _slep_000: + +============================== +SLEP000: SLEP and its wofkflow +============================== + +:Author: Adrin Jalali +:Status: Draft +:Type: Process +:Created: 2020-02-13 + +Abstract +######## + +This SLEP specifies details related to SLEP submission, review, and acceptance +process. + +Motivation +########## + +Without a predefined workflow, the discussions around a SLEP can be long and +frustrating for both the author and the reviewers. The lack of a known workflow +also results in the SLEPs to take months (if not years) before it is accepted +as ``Draft``. The purpose of this SLEP is to lubricate and ease the +process of working on a SLEP, and make it a more enjoyable and productive +experience. + + +What is a SLEP? +############### + +SLEP stands for Scikit-Learn Enhancement Proposal. A SLEP is a design document +providing information to the scikit-learn community, or describing a new +feature for scikit-learn or its processes or environment. The SLEP should +provide a concise technical specification of the feature and a rationale for +the feature. + +We intend SLEPs to be the primary mechanisms for proposing major new features, +for collecting community input on an issue, and for documenting the design +decisions that have gone into scikit-learn. The SLEP author is responsible for +building consensus within the community and documenting dissenting opinions. + +Because the SLEPs are maintained as text files in a versioned repository, their +revision history is the historical record of the feature proposal. + +SLEP Audience +############# + +The typical primary audience for SLEPs are the core developers of +``scikit-learn`` and technical committee, as well as contributors to the +project. However, these documents also serve the purpose of documenting the +changes and decisions to help users understand the changes and why they are +made. + +The proposal should be submitted as a draft SLEP via a GitHub pull request to a +``slepXXX`` directory with the name ``proposal.rst`` where ``XXX`` is an +appropriately assigned three-digit number (e.g., ``slep000/proposal.rst``). The +draft must use the SLEP — Template and Instructions file. + +Once the PR for the SLEP is in place, a post should be made to the mailing list +containing the sections up to “Backward compatibility”, with the purpose of +limiting discussion there to usage and impact. Discussion on the pull request +will have a broader scope, also including details of implementation. + +At the earliest convenience, the PR should be merged (regardless of whether it +is accepted during discussion). Additional PRs may be made by the champions to +update or expand the SLEP, or by maintainers to set its status, discussion URL, +etc. + +Standards Track SLEPs consist of two parts, a design document and a reference +implementation. It is generally recommended that at least a prototype +implementation be co-developed with the SLEP, as ideas that sound good in +principle sometimes turn out to be impractical when subjected to the test of +implementation. Often it makes sense for the prototype implementation to be +made available as PR to the scikit-learn repo (making sure to appropriately +mark the PR as a WIP). + +SLEP Types +########## + +There are three kinds of SLEPs: + +1. A Standards Track SLEP describes a new feature or implementation for +scikit-learn. + +2. An Informational SLEP describes a scikit-learn design issue, or provides +general guidelines or information to the scikit-learn community, but does not +propose a new feature. Informational SLEPs do not necessarily represent a +scikit-learn community consensus or recommendation, so users and implementers +are free to ignore Informational SLEPs or follow their advice. + +3. A Process SLEP describes a process surrounding scikit-learn, or proposes a +change to (or an event in) a process. Process SLEPs are like Standards Track +SLEPs but apply to areas other than the scikit-learn library itself. They may +propose an implementation, but not to scikit-learn’s codebase; they require +community consensus. Examples include procedures, guidelines, changes to the +decision-making process, and changes to the tools or environment used in +scikit-learn development. Any meta-SLEP is also considered a Process SLEP. + + +SLEP Workflow +############# + +A SLEP starts with an idea, which usually is discussed in an issue or a pull +request on the main repo before submitting a SLEP. It is generally a good idea +for the author of the SLEP to gauge the viability and the interest of the +community before working on a SLEP, mostly to save author's time. + +A SLEP must have one or more champions: people who write the SLEP following the +SLEP template, shepherd the discussions around it, and seek consensus in the +community. + +Review and Resolution +--------------------- + +SLEPs are discussed on the mailing list or the PRs modifying the SLEP. The +possible paths of the status of SLEPs are as follows: + +.. image:: pep-0001-process_flow.png + :alt: SLEP process flow diagram + +All SLEPs should be created with the ``Draft`` status. + +Eventually, after discussion, there may be a consensus that the SLEP should be +accepted – see the next section for details. At this point the status becomes +``Accepted``. + +Once a SLEP has been ``Accepted``, the reference implementation must be +completed. When the reference implementation is complete and incorporated into +the main source code repository, the status will be changed to ``Final``. + +To allow gathering of additional design and interface feedback before +committing to long term stability for a language feature or standard library +API, a SLEP may also be marked as ``Provisional``. This is short for +“Provisionally Accepted”, and indicates that the proposal has been accepted for +inclusion in the reference implementation, but additional user feedback is +needed before the full design can be considered ``Final``. Unlike regular +accepted SLEPs, provisionally accepted SLEPs may still be ``Rejected`` or +``Withdrawn`` even after the related changes have been included in a +scikit-learn release. + +Wherever possible, it is considered preferable to reduce the scope of a +proposal to avoid the need to rely on the ``Provisional`` status (e.g. by +deferring some features to later SLEPs), as this status can lead to version +compatibility challenges in the wider scikit-learn ecosystem. + +A SLEP can also be assigned status ``Deferred``. The SLEP author or a core +developer can assign the SLEP this status when no progress is being made on the +SLEP. + +A SLEP can also be ``Rejected``. Perhaps after all is said and done it was not +a good idea. It is still important to have a record of this fact. The +``Withdrawn`` status is similar; it means that the SLEP author themselves has +decided that the SLEP is actually a bad idea, or has accepted that a competing +proposal is a better alternative. + +When a SLEP is ``Accepted``, ``Rejected``, or ``Withdrawn``, the SLEP should be +updated accordingly. In addition to updating the status field, at the very +least the ``Resolution`` header should be added with a link to the relevant +thread in the mailing list archives or where the discussion happened. + +SLEPs can also be ``Superseded`` by a different SLEP, rendering the original +obsolete. The ``Replaced-By`` and ``Replaces`` headers should be added to the +original and new SLEPs respectively. + +``Process`` SLEPs may also have a status of ``Active`` if they are never meant +to be completed, e.g. SLEP 1 (this SLEP). + +How a SLEP becomes Accepted +--------------------------- + +A SLEP is ``Accepted`` by the voting mechanism defined in the governance model. +We need a concrete way to tell whether consensus has been reached. When you +think a SLEP is ready to accept, create a PR changing the status of the SLEP to +``Accepted``, then send an email to the scikit-learn mailing list with a +subject like: + + Proposal to accept SLEP #: + +In the body of your email, you should: + +- link to the latest version of the SLEP, and a link to the PR accepting the + SLEP. + +- briefly describe any major points of contention and how they were resolved, + +- include a sentence like: “The vote will be closed in a month.” + +Generally the SLEP author will be the one to send this email, but anyone can do +it; the important thing is to make sure that everyone knows when a SLEP is on +the verge of acceptance, and give them a final chance to respond. + +In general, the goal is to make sure that the community has consensus, not +provide a rigid policy for people to try to game. When in doubt, err on the +side of asking for more feedback and looking for opportunities to compromise. + +If the final comment and voting period passes with the required majority, then +the SLEP can officially be marked ``Accepted``. The ``Resolution`` header +should link to the PR accepting the SLEP. + +If the vote does not achieve a required majority, then the SLEP remains in +``Draft`` state, discussion continues as normal, and it can be proposed for +acceptance again later once the objections are resolved. + +In unusual cases, with the request of the author, the scikit-learn technical +committee may be asked to decide whether a controversial SLEP is ``Accepted``. + +Maintenance +----------- + +In general, Standards track SLEPs are no longer modified after they have +reached the ``Final`` state as the code and project documentation are +considered the ultimate reference for the implemented feature. However, +finalized Standards track SLEPs may be updated as needed. + +Process SLEPs may be updated over time to reflect changes to development +practices and other details. The precise process followed in these cases will +depend on the nature and purpose of the SLEP being updated. + +Format and Template +------------------- + +SLEPs are UTF-8 encoded text files using the `reStructuredText +<http://docutils.sourceforge.net/rst.html>`_ format. Please see the `SLEP — +Template and Instructions +<https://github.com/scikit-learn/enhancement_proposals/blob/master/slep_template.rst>`_ +file and the `reStructuredTextPrimer +<https://www.sphinx-doc.org/en/stable/rest.html>`_ for more information. We use +`Sphinx <https://www.sphinx-doc.org/en/stable/>`_ to convert SLEPs to HTML for +viewing on the web. + +Header Preamble +--------------- + +Each SLEP must begin with a header preamble. The headers must appear in the +following order. Headers marked with * are optional. All other headers are +required:: + + :Author: <list of authors' real names and optionally, email addresses> + :Status: <Draft | Active | Accepted | Deferred | Rejected | + Withdrawn | Final | Superseded> + :Type: <Standards Track | Informational | Process> + :Created: <date created on, in yyyy-mm-dd format> + * :Requires: <slep numbers> + * :scikit-learn-Version: <version number> + * :Replaces: <slep number> + * :Replaced-By: <slep number> + * :Resolution: <url> + +The Author header lists the names, and optionally the email addresses of all +the authors of the SLEP. The format of the Author header value must be + + Random J. User <address@dom.ain> + +if the email address is included, and just + + Random J. User + +if the address is not given. If there are multiple authors, each should be on a +separate line. + +Copyright +--------- + +This document has been placed in the public domain [1]_. + +References and Footnotes +------------------------ + +.. [1] _Open Publication License: https://www.opencontent.org/openpub/ From 6d24c52fceb2df9e6261550a0b3ede002b881fe3 Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Thu, 13 Feb 2020 14:20:32 +0100 Subject: [PATCH 02/15] rename folder --- {slep013 => slep000}/pep-0001-process_flow.png | Bin {slep013 => slep000}/proposal.rst | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename {slep013 => slep000}/pep-0001-process_flow.png (100%) rename {slep013 => slep000}/proposal.rst (100%) diff --git a/slep013/pep-0001-process_flow.png b/slep000/pep-0001-process_flow.png similarity index 100% rename from slep013/pep-0001-process_flow.png rename to slep000/pep-0001-process_flow.png diff --git a/slep013/proposal.rst b/slep000/proposal.rst similarity index 100% rename from slep013/proposal.rst rename to slep000/proposal.rst From d296bcb4c2ff5e5d3c15e0b492a1ba9d0cc95a56 Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Thu, 13 Feb 2020 16:06:38 +0100 Subject: [PATCH 03/15] address Guillaume's comments --- slep000/proposal.rst | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index 5457ef6..08c7229 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -19,9 +19,9 @@ Motivation ########## Without a predefined workflow, the discussions around a SLEP can be long and -frustrating for both the author and the reviewers. The lack of a known workflow -also results in the SLEPs to take months (if not years) before it is accepted -as ``Draft``. The purpose of this SLEP is to lubricate and ease the +frustrating for both the author(s) and the reviewers. The lack of a known +workflow also results in the SLEPs to take months (if not years) before it is +accepted as ``Draft``. The purpose of this SLEP is to lubricate and ease the process of working on a SLEP, and make it a more enjoyable and productive experience. @@ -130,14 +130,13 @@ completed. When the reference implementation is complete and incorporated into the main source code repository, the status will be changed to ``Final``. To allow gathering of additional design and interface feedback before -committing to long term stability for a language feature or standard library -API, a SLEP may also be marked as ``Provisional``. This is short for -“Provisionally Accepted”, and indicates that the proposal has been accepted for -inclusion in the reference implementation, but additional user feedback is -needed before the full design can be considered ``Final``. Unlike regular -accepted SLEPs, provisionally accepted SLEPs may still be ``Rejected`` or -``Withdrawn`` even after the related changes have been included in a -scikit-learn release. +committing to long term stability for a feature or API, a SLEP may also be +marked as ``Provisional``. This is short for“Provisionally Accepted”, and +indicates that the proposal has been accepted for inclusion in the reference +implementation, but additional user feedback is needed before the full design +can be considered ``Final``. Unlike regular accepted SLEPs, provisionally +accepted SLEPs may still be ``Rejected`` or ``Withdrawn`` even after the +related changes have been included in a scikit-learn release. Wherever possible, it is considered preferable to reduce the scope of a proposal to avoid the need to rely on the ``Provisional`` status (e.g. by From 2d3fca659042fb340bbc034c3481d79ad8b315bf Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Thu, 13 Feb 2020 16:16:55 +0100 Subject: [PATCH 04/15] address Nicolas's comments --- slep000/proposal.rst | 43 ++++++++++++++++++++++++------------------- 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index 08c7229..e74c3b3 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -1,7 +1,7 @@ .. _slep_000: ============================== -SLEP000: SLEP and its wofkflow +SLEP000: SLEP and its workflow ============================== :Author: Adrin Jalali @@ -29,11 +29,11 @@ experience. What is a SLEP? ############### -SLEP stands for Scikit-Learn Enhancement Proposal. A SLEP is a design document -providing information to the scikit-learn community, or describing a new -feature for scikit-learn or its processes or environment. The SLEP should -provide a concise technical specification of the feature and a rationale for -the feature. +SLEP stands for Scikit-Learn Enhancement Proposal, inspired from Python PEPs or +Numpy NEPs. A SLEP is a design document providing information to the +scikit-learn community, or describing a new feature for scikit-learn or its +processes or environment. The SLEP should provide a concise technical +specification of the proposed solution, and a rationale for the feature. We intend SLEPs to be the primary mechanisms for proposing major new features, for collecting community input on an issue, and for documenting the design @@ -50,12 +50,15 @@ The typical primary audience for SLEPs are the core developers of ``scikit-learn`` and technical committee, as well as contributors to the project. However, these documents also serve the purpose of documenting the changes and decisions to help users understand the changes and why they are -made. +made. The SLEPs are available under `Scikit-learn enhancement proposals +<https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/>`_. The proposal should be submitted as a draft SLEP via a GitHub pull request to a ``slepXXX`` directory with the name ``proposal.rst`` where ``XXX`` is an appropriately assigned three-digit number (e.g., ``slep000/proposal.rst``). The -draft must use the SLEP — Template and Instructions file. +draft must use the `SLEP — Template and Instructions +<https://github.com/scikit-learn/enhancement_proposals/blob/master/slep_template.rst>`_ +file. Once the PR for the SLEP is in place, a post should be made to the mailing list containing the sections up to “Backward compatibility”, with the purpose of @@ -67,13 +70,13 @@ is accepted during discussion). Additional PRs may be made by the champions to update or expand the SLEP, or by maintainers to set its status, discussion URL, etc. -Standards Track SLEPs consist of two parts, a design document and a reference -implementation. It is generally recommended that at least a prototype -implementation be co-developed with the SLEP, as ideas that sound good in -principle sometimes turn out to be impractical when subjected to the test of -implementation. Often it makes sense for the prototype implementation to be -made available as PR to the scikit-learn repo (making sure to appropriately -mark the PR as a WIP). +Standards Track SLEPs (see bellow) consist of two parts, a design document and +a reference implementation. It is generally recommended that at least a +prototype implementation be co-developed with the SLEP, as ideas that sound +good in principle sometimes turn out to be impractical when subjected to the +test of implementation. Often it makes sense for the prototype implementation +to be made available as PR to the scikit-learn repo (making sure to +appropriately mark the PR as a WIP). SLEP Types ########## @@ -168,9 +171,10 @@ to be completed, e.g. SLEP 1 (this SLEP). How a SLEP becomes Accepted --------------------------- -A SLEP is ``Accepted`` by the voting mechanism defined in the governance model. -We need a concrete way to tell whether consensus has been reached. When you -think a SLEP is ready to accept, create a PR changing the status of the SLEP to +A SLEP is ``Accepted`` by the voting mechanism defined in the `governance model +<https://scikit-learn.org/stable/governance.html?highlight=governance>`_. We +need a concrete way to tell whether consensus has been reached. When you think +a SLEP is ready to accept, create a PR changing the status of the SLEP to ``Accepted``, then send an email to the scikit-learn mailing list with a subject like: @@ -183,7 +187,8 @@ In the body of your email, you should: - briefly describe any major points of contention and how they were resolved, -- include a sentence like: “The vote will be closed in a month.” +- include a sentence like: “The vote will be closed in a month i.e. on + <the_date>.” Generally the SLEP author will be the one to send this email, but anyone can do it; the important thing is to make sure that everyone knows when a SLEP is on From bf2191f171634cf4ea8a52d608931635cec6c8fc Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Thu, 13 Feb 2020 16:33:27 +0100 Subject: [PATCH 05/15] in place -> created --- slep000/proposal.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index e74c3b3..46580fe 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -60,7 +60,7 @@ draft must use the `SLEP — Template and Instructions <https://github.com/scikit-learn/enhancement_proposals/blob/master/slep_template.rst>`_ file. -Once the PR for the SLEP is in place, a post should be made to the mailing list +Once the PR for the SLEP is created, a post should be made to the mailing list containing the sections up to “Backward compatibility”, with the purpose of limiting discussion there to usage and impact. Discussion on the pull request will have a broader scope, also including details of implementation. From fb32fa06381cfcf6d901a7bb60f7792207a0fcf6 Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Thu, 13 Feb 2020 16:34:59 +0100 Subject: [PATCH 06/15] accepted -> merged --- slep000/proposal.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index 46580fe..8cfee04 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -21,7 +21,7 @@ Motivation Without a predefined workflow, the discussions around a SLEP can be long and frustrating for both the author(s) and the reviewers. The lack of a known workflow also results in the SLEPs to take months (if not years) before it is -accepted as ``Draft``. The purpose of this SLEP is to lubricate and ease the +merged as ``Draft``. The purpose of this SLEP is to lubricate and ease the process of working on a SLEP, and make it a more enjoyable and productive experience. From 0e01bb4fb3685627dba7b2e6dd296fa0077ff0bf Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Thu, 13 Feb 2020 16:42:42 +0100 Subject: [PATCH 07/15] slight rephrasing of the abstract --- slep000/proposal.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index 8cfee04..e7b3ada 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -21,9 +21,10 @@ Motivation Without a predefined workflow, the discussions around a SLEP can be long and frustrating for both the author(s) and the reviewers. The lack of a known workflow also results in the SLEPs to take months (if not years) before it is -merged as ``Draft``. The purpose of this SLEP is to lubricate and ease the -process of working on a SLEP, and make it a more enjoyable and productive -experience. +merged as ``Under Review``. The purpose of this SLEP is to lubricate and ease +the process of working on a SLEP, and make it a more enjoyable and productive +experience. It also used the process used in PEPs and NEPs which means there +will be no ``Under Review`` status. What is a SLEP? From 4c4286342b535a709ac827f6b5596d8ac2328c7c Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Mon, 17 Feb 2020 17:25:03 +0100 Subject: [PATCH 08/15] clarify the 'it also used...' sentence --- slep000/proposal.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index e7b3ada..f7b451a 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -23,8 +23,8 @@ frustrating for both the author(s) and the reviewers. The lack of a known workflow also results in the SLEPs to take months (if not years) before it is merged as ``Under Review``. The purpose of this SLEP is to lubricate and ease the process of working on a SLEP, and make it a more enjoyable and productive -experience. It also used the process used in PEPs and NEPs which means there -will be no ``Under Review`` status. +experience. This SLEP borrows the process used in PEPs and NEPs which means +there will be no ``Under Review`` status. What is a SLEP? From 5155b22944c2293f598704f470082782b20fb2f8 Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Mon, 17 Feb 2020 17:43:46 +0100 Subject: [PATCH 09/15] Gael's suggestions --- slep000/proposal.rst | 62 ++++++++++++++++++++++---------------------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index f7b451a..d8ccd9c 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -19,12 +19,12 @@ Motivation ########## Without a predefined workflow, the discussions around a SLEP can be long and -frustrating for both the author(s) and the reviewers. The lack of a known -workflow also results in the SLEPs to take months (if not years) before it is -merged as ``Under Review``. The purpose of this SLEP is to lubricate and ease -the process of working on a SLEP, and make it a more enjoyable and productive -experience. This SLEP borrows the process used in PEPs and NEPs which means -there will be no ``Under Review`` status. +consume a lot of energy for both the author(s) and the reviewers. The lack of a +known workflow also results in the SLEPs to take months (if not years) before +it is merged as ``Under Review``. The purpose of this SLEP is to lubricate and +ease the process of working on a SLEP, and make it a more enjoyable and +productive experience. This SLEP borrows the process used in PEPs and NEPs +which means there will be no ``Under Review`` status. What is a SLEP? @@ -54,31 +54,6 @@ changes and decisions to help users understand the changes and why they are made. The SLEPs are available under `Scikit-learn enhancement proposals <https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/>`_. -The proposal should be submitted as a draft SLEP via a GitHub pull request to a -``slepXXX`` directory with the name ``proposal.rst`` where ``XXX`` is an -appropriately assigned three-digit number (e.g., ``slep000/proposal.rst``). The -draft must use the `SLEP — Template and Instructions -<https://github.com/scikit-learn/enhancement_proposals/blob/master/slep_template.rst>`_ -file. - -Once the PR for the SLEP is created, a post should be made to the mailing list -containing the sections up to “Backward compatibility”, with the purpose of -limiting discussion there to usage and impact. Discussion on the pull request -will have a broader scope, also including details of implementation. - -At the earliest convenience, the PR should be merged (regardless of whether it -is accepted during discussion). Additional PRs may be made by the champions to -update or expand the SLEP, or by maintainers to set its status, discussion URL, -etc. - -Standards Track SLEPs (see bellow) consist of two parts, a design document and -a reference implementation. It is generally recommended that at least a -prototype implementation be co-developed with the SLEP, as ideas that sound -good in principle sometimes turn out to be impractical when subjected to the -test of implementation. Often it makes sense for the prototype implementation -to be made available as PR to the scikit-learn repo (making sure to -appropriately mark the PR as a WIP). - SLEP Types ########## @@ -114,6 +89,31 @@ A SLEP must have one or more champions: people who write the SLEP following the SLEP template, shepherd the discussions around it, and seek consensus in the community. +The proposal should be submitted as a draft SLEP via a GitHub pull request to a +``slepXXX`` directory with the name ``proposal.rst`` where ``XXX`` is an +appropriately assigned three-digit number (e.g., ``slep000/proposal.rst``). The +draft must use the `SLEP — Template and Instructions +<https://github.com/scikit-learn/enhancement_proposals/blob/master/slep_template.rst>`_ +file. + +Once the PR for the SLEP is created, a post should be made to the mailing list +containing the sections up to “Backward compatibility”, with the purpose of +limiting discussion there to usage and impact. Discussion on the pull request +will have a broader scope, also including details of implementation. + +At the earliest convenience, the PR should be merged (regardless of whether it +is accepted during discussion). Additional PRs may be made by the champions to +update or expand the SLEP, or by maintainers to set its status, discussion URL, +etc. + +Standards Track SLEPs (see bellow) consist of two parts, a design document and +a reference implementation. It is generally recommended that at least a +prototype implementation be co-developed with the SLEP, as ideas that sound +good in principle sometimes turn out to be impractical when subjected to the +test of implementation. Often it makes sense for the prototype implementation +to be made available as PR to the scikit-learn repo (making sure to +appropriately mark the PR as a WIP). + Review and Resolution --------------------- From 845255bf0685daba749eda47cf73237ac0999537 Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Tue, 18 Feb 2020 20:47:57 +0100 Subject: [PATCH 10/15] revised merge criteria --- slep000/proposal.rst | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index d8ccd9c..101aeed 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -101,10 +101,20 @@ containing the sections up to “Backward compatibility”, with the purpose of limiting discussion there to usage and impact. Discussion on the pull request will have a broader scope, also including details of implementation. -At the earliest convenience, the PR should be merged (regardless of whether it -is accepted during discussion). Additional PRs may be made by the champions to -update or expand the SLEP, or by maintainers to set its status, discussion URL, -etc. +The SLEP is reviewed for structure, formatting, and other errors. Approval +criteria are: + +- It sound and complete. The ideas must make technical sense. +- The reviewers do not consider whether they seem likely to be accepted. +- The title accurately describes the content. + +Reviewers are generally quite lenient about this initial review, expecting that +problems will be corrected by the further reviewing process. **Note**: Approval +of the SLEP is no guarantee that there are no embarrassing mistakes! Ideally +they're avoided, but they can also be fixed later in separate PRs. Once +approved by at least one core developer, the SLEP can be merged. Additional PRs +may be made by the champions to update or expand the SLEP, or by maintainers to +set its status, discussion URL, etc. Standards Track SLEPs (see bellow) consist of two parts, a design document and a reference implementation. It is generally recommended that at least a @@ -135,7 +145,7 @@ the main source code repository, the status will be changed to ``Final``. To allow gathering of additional design and interface feedback before committing to long term stability for a feature or API, a SLEP may also be -marked as ``Provisional``. This is short for“Provisionally Accepted”, and +marked as ``Provisional``. This is short for "Provisionally Accepted", and indicates that the proposal has been accepted for inclusion in the reference implementation, but additional user feedback is needed before the full design can be considered ``Final``. Unlike regular accepted SLEPs, provisionally From 10f1a80903b9bb3c95b36dfae52341dcb6934142 Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Mon, 24 Feb 2020 11:50:36 +0100 Subject: [PATCH 11/15] further clarify initial approval --- slep000/proposal.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index 101aeed..f380c67 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -101,8 +101,10 @@ containing the sections up to “Backward compatibility”, with the purpose of limiting discussion there to usage and impact. Discussion on the pull request will have a broader scope, also including details of implementation. -The SLEP is reviewed for structure, formatting, and other errors. Approval -criteria are: +The first draft of the SLEP needs to be approved by at least one core developer +before being merged. Merging the draft does not mean it is accepted or is ready +for the vote. To this end, the SLEP draft is reviewed for structure, +formatting, and other errors. Approval criteria are: - It sound and complete. The ideas must make technical sense. - The reviewers do not consider whether they seem likely to be accepted. From 77cc0770ecc350257ae67fa00ccf9b7f0cb2f71a Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Tue, 25 Feb 2020 09:56:54 +0100 Subject: [PATCH 12/15] SLEP -> SLEP draft --- slep000/proposal.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index f380c67..817189c 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -112,11 +112,11 @@ formatting, and other errors. Approval criteria are: Reviewers are generally quite lenient about this initial review, expecting that problems will be corrected by the further reviewing process. **Note**: Approval -of the SLEP is no guarantee that there are no embarrassing mistakes! Ideally -they're avoided, but they can also be fixed later in separate PRs. Once -approved by at least one core developer, the SLEP can be merged. Additional PRs -may be made by the champions to update or expand the SLEP, or by maintainers to -set its status, discussion URL, etc. +of the SLEP draft is no guarantee that there are no embarrassing mistakes! +Ideally they're avoided, but they can also be fixed later in separate PRs. Once +approved by at least one core developer, the SLEP draft can be merged. +Additional PRs may be made by the champions to update or expand the SLEP, or by +maintainers to set its status, discussion URL, etc. Standards Track SLEPs (see bellow) consist of two parts, a design document and a reference implementation. It is generally recommended that at least a From dbb936dc74ff137d38f266fca78bb2ec07c3e0d2 Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Fri, 28 Feb 2020 12:21:04 +0100 Subject: [PATCH 13/15] address Olivier's comments --- slep000/proposal.rst | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index 817189c..a5f6d43 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -106,9 +106,10 @@ before being merged. Merging the draft does not mean it is accepted or is ready for the vote. To this end, the SLEP draft is reviewed for structure, formatting, and other errors. Approval criteria are: -- It sound and complete. The ideas must make technical sense. -- The reviewers do not consider whether they seem likely to be accepted. -- The title accurately describes the content. +- The draft is sound and complete. The ideas must make technical sense. +- The initial PR reviewer(s) should not consider whether the SLEP seems likely + to be accepted. +- The title of the SLEP draft accurately describes its content. Reviewers are generally quite lenient about this initial review, expecting that problems will be corrected by the further reviewing process. **Note**: Approval @@ -191,7 +192,7 @@ a SLEP is ready to accept, create a PR changing the status of the SLEP to ``Accepted``, then send an email to the scikit-learn mailing list with a subject like: - Proposal to accept SLEP #<number>: <title> + [VOTE] Proposal to accept SLEP #<number>: <title> In the body of your email, you should: @@ -220,7 +221,10 @@ If the vote does not achieve a required majority, then the SLEP remains in acceptance again later once the objections are resolved. In unusual cases, with the request of the author, the scikit-learn technical -committee may be asked to decide whether a controversial SLEP is ``Accepted``. +committee may be asked to decide whether a controversial SLEP is ``Accepted``, +put back to ``Draft`` with additional recommendation to try again to reach +consensus or definitely ``Rejected``. Please refer to the governance doc for +more details. Maintenance ----------- From 8ca1a829dd6a8adae2ec2944e9778c231f6f17ed Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Mon, 29 Nov 2021 16:49:19 +0100 Subject: [PATCH 14/15] add Guillaume's suggestion --- slep000/proposal.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index a5f6d43..9462c21 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -144,7 +144,9 @@ accepted – see the next section for details. At this point the status becomes Once a SLEP has been ``Accepted``, the reference implementation must be completed. When the reference implementation is complete and incorporated into -the main source code repository, the status will be changed to ``Final``. +the main source code repository, the status will be changed to ``Final``. Since +most SLEPs deal with a part of scikit-learn's API, another way of viewing a +SLEP as ``Final`` is when its corresponding API interface is considered stable. To allow gathering of additional design and interface feedback before committing to long term stability for a feature or API, a SLEP may also be From 888aabed16bf3c34e7771266b86dd96701c80bdf Mon Sep 17 00:00:00 2001 From: adrinjalali <adrin.jalali@gmail.com> Date: Tue, 30 Nov 2021 14:11:25 +0100 Subject: [PATCH 15/15] Andy's comments --- slep000/proposal.rst | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/slep000/proposal.rst b/slep000/proposal.rst index 9462c21..48c9572 100644 --- a/slep000/proposal.rst +++ b/slep000/proposal.rst @@ -66,15 +66,20 @@ scikit-learn. general guidelines or information to the scikit-learn community, but does not propose a new feature. Informational SLEPs do not necessarily represent a scikit-learn community consensus or recommendation, so users and implementers -are free to ignore Informational SLEPs or follow their advice. +are free to ignore Informational SLEPs or follow their advice. For instance, an +informational SLEP could be one explaining how people can write a third party +estimator, one to explain the usual process of adding a package to the contrib +org, or what our inclusion criteria are for scikit-learn and +scikit-learn-extra. 3. A Process SLEP describes a process surrounding scikit-learn, or proposes a change to (or an event in) a process. Process SLEPs are like Standards Track SLEPs but apply to areas other than the scikit-learn library itself. They may propose an implementation, but not to scikit-learn’s codebase; they require community consensus. Examples include procedures, guidelines, changes to the -decision-making process, and changes to the tools or environment used in -scikit-learn development. Any meta-SLEP is also considered a Process SLEP. +decision-making process and the governance document, and changes to the tools +or environment used in scikit-learn development. Any meta-SLEP is also +considered a Process SLEP. SLEP Workflow