beta delivery and beyond WAS: Users first (was Re: Pull requests need to be reviewed)

[Eduard Karel de Jong <ed...@dejongfrz.nl>]

I can't agree more with Antonio and Geertjan: as a community we need to 
keep our eyes focussed on the goal: delivering a superior IDE to 
developers. And doing so in a timely fashion.

My earlier suggestions about voting to move forward with a beta release 
intended to support keeping that focus. From the many things that could 
be improved in the code, and with such a large code base and extensive 
functionality there alway will be a lot of these, we need to identify 
which will be essential to realise before getting to the next stage of 
release.

As an open source project we need to find a balance between on one side, 
sustaining a vibrant community, where many are engaged and feel 
appreciate for their various roles, and in efficiently making 
decissions. To be specific, democracy is great for the former but may at 
times be too slow and not explicit enough for the latter.

After a community decision to have a beta release we will need a small 
committee to rank any changes to code and functions that should be 
realised before the next stage. In my view Geertjan, possibly together 
with a couple of others should have that task, the task of identifying 
these essential additions to the beta code base. The  input for the 
decision on essential PRs should be, primarily, in my proposal, from the 
issues provided accompanying the vote to go to beta. And, next to 
setting the priorities that small group should set a date by which the 
next release stage should ideally be ready.

With that date for a next release known, any PR that was not qualified 
as a priority and for which some members in the community had the energy 
to address the issue in time could still be considered for integration. 
Such additional PRs could be required to be ready some time before the 
times set for the essential ones to give time for deciding on them 
without interfering with the main line of the delivery schedule.

A further thought on the small committee that takes those decisions 
about timely moving from beta to the next stage in the release, in 
addition to a small core of one or two people, members of the community 
could self nominate for membership thereof. To that end the size of the 
committee, let's call them the "release shepherds' has a maximum size, 
7, or so, and self nomination happens in two stages: first, interest to 
be involved as release shepherd is indicated on the ballot response, 
secondly, if there are more candidates, those interested discuss amongst 
themselves who of them will be a shepherd this time. As background, I 
have very good experience with self nomination for the governance of  a 
very long-running (30+ years) of a no-conference i participate in 
(Consultants' Camp <http://www.consultantscamp.org>).

In summary, the idea i developed here,  is to structure a vote for beta 
release to have three parts:
— up/down/don't care (=+1/-1/0), this is required to be a real vote
-—One or more PRs the voter considers essential to integrate before the 
next stage. Optional with +1 vote,  required with a -1 vote.
-—Self nomination as shepherd, optional.
The idea to require at least one PR with a negative vote is borrowed 
from international standardisation with ISO. The idea is that addressing 
these issues would change the vote to, at least, don't care (=0).
These rules should apply only to a vote for a beta release at that's 
when we, as a community, decide it's really ready to release, so that 
release should happen sooner rather than later.

I realise all this is getting a a bit more than 2¢. Sorry about that. At 
this point in time, I don't have much time to contribute to the coding 
effort, yet I like to support NB as it moves into open source, by 
sharing some of my experiences with open organisations and democratic 
decisions in standardisation and in (city) politics. These ideas may be 
worth a dedicated thread of discussion. Anyway, there's no harm in 
experimenting and adjusting based on what we learn.

Cheers
Eduard


Antonio wrote:
> Hi,
>
> My 2 cents: I agree with Geertjan: I think we should concentrate our 
> efforts in the best NetBeans 9 we can build for users. There're many 
> important things to do, ranging from the website to the jdk-javac 
> branch. And many new tools to control, ranging from the wiki to the 
> very slow JIRA issue tracker.
>
> I think we should stay focused in those things that worry users, for 
> the benefit of the users, and leave those code-cosmetic, internal 
> changes for later on. After all NetBeans users deserve the best IDE we 
> can build, and it does not really matter to them if we're improving 
> the readability of ternary operators or if we're replacing for loops 
> with the Streaming API.
>
> NetBeans is the second Apache project by size (as per [1]), with more 
> than 5.5M lines of code. Making those millions of lines of code more 
> readable & pretty may be a perfect academic case study, but spending 
> our efforts on those areas won't make our users more happy.
>
> Cheers,
> Antonio
>
> [1]
> Apache in 2017 - By The Digits
> https://blogs.apache.org/foundation/entry/apache-in-2017-by-the
>
> On 12/01/18 11:54, Geertjan Wielenga wrote:
>> On Friday, January 12, 2018, Christian Lenz <ch...@gmx.net> 
>> wrote:
>>
>>> Hi,
>>>
>>> first, in my opinion each PR is welcome, why not cosmetic stuff too? 
>>> There
>>> is always a need to refactor code to make it more readable, 
>>> maintainable
>>> and sometimes or more often it makes stuff faster. So why not accepting
>>> everything?
>>
>>
>>
>> The concern is that we could end up with hundreds of PRs that are 
>> nothing
>> more than small tweaks for no clear reason, drowning out PRs such as 
>> yours
>> that provide new meaningful features.
>>
>> We do need to discuss this, probably in a new thread, but I’d suggest 
>> each
>> PR needs to start off with a new issue describing exactly what the 
>> problem
>> is, with the proposed solution, followed by some discussion, after 
>> which a
>> PR is made. Refactoring for the sake of refactoring, without any 
>> planning
>> or motivation, could lead to chaos.
>>
>> Gj
>>
>>
>>
>>>
>>> Yes I think we need guidelines too. Like „when do we need Tests“, 
>>> „how a
>>> commit should look like“, etc. and we need more branches. I mean atm we
>>> have develop, master and some feature branches?
>>>
>>> So develop should be the next release. Until a specific point, we 
>>> need a
>>> relase branch like release/nb9 maybe for Alpha/beta and or rc state. 
>>> So we
>>> have a fixed state where we can fix bugs and stuff but no new 
>>> features. New
>>> features until beta or rc, should be done in feature branches and 
>>> merged
>>> into develop, where this is NB9.1 or whatever.
>>>
>>> Than there will be no discussion about whether we can handle or we have
>>> time for „luxury“ stuff or not. Each PR, which is not a bug fix and
>>> important for the next release, is done inside the dev state when we 
>>> have a
>>> release branch.
>>>
>>>
>>> Cheers
>>>
>>> Chris
>>>
>>>
>>> Von: Neil C Smith
>>> Gesendet: Freitag, 12. Januar 2018 10:02
>>> An: dev@netbeans.incubator.apache.org
>>> Betreff: Re: Pull requests need to be reviewed
>>>
>>> On Fri, 12 Jan 2018 at 08:04 Geertjan Wielenga <
>>> geertjan.wielenga@googlemail.com> wrote:
>>>
>>>> I think we need to set up guidelines — e.g., a PR must be connected 
>>>> to an
>>>> issue; a PR must solve a problem and not be cosmetic only; etc.
>>>>
>>>> I’d advise looking at pull/3 by Chris instead.
>>>>
>>>
>>> I like Chris' PR, and see the benefit of it ... but, within those
>>> guidelines are we going to have the concept of feature freeze?  In my
>>> opinion, if we're in beta vote phase, we should also only be 
>>> accepting bug
>>> fixes.  In which case, I'd be tempted to push that back to the next 
>>> point
>>> release?
>>>
>>> Out of interest, what were the old NetBeans policies around feature
>>> freezing / release planning?
>>>
>>> Best wishes,
>>>
>>> Neil
>>>
>>>
>>>
>>> -- 
>>> Neil C Smith
>>> Artist & Technologist
>>> www.neilcsmith.net
>>>
>>> Praxis LIVE - hybrid visual IDE for creative coding - 
>>> www.praxislive.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: beta delivery and beyond WAS: Users first (was Re: Pull requests need to be reviewed)

[Neil C Smith <ne...@apache.org>]

Hi,

On Sat, 13 Jan 2018 at 09:02 Eduard Karel de Jong <ed...@dejongfrz.nl>
wrote:

> yet I like to support NB as it moves into open source, by
> sharing some of my experiences with open organisations and democratic
> decisions in standardisation and in (city) politics.
>

Interesting read.  It seems you and I have similar backgrounds - city
politics can make anyone sceptical of democracy in action! ;-)

However, if you haven't already, I would look at all the Apache information
/ guidelines on decision making.  I think they're fairly good (have pointed
people in a completely different open organisation context at them
recently), and whatever we do needs to fit within them anyway.

Replace PR with JIRA ticket in your suggestions on votes and I'd agree with
that personally.

Best wishes,

Neil


-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org