netbeans-netcat mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Romanenko <>
Subject Re: Some of my thought regarding NetCAT 10
Date Wed, 31 Oct 2018 21:31:05 GMT
> the dev team cannot address each issue..." makes no sense because there
is no dev team
Hierarchy of mailing lists, segregation of netcat vs dev worklow on the
website and schedule process implies otherwise. It may not be intentional
but that's what it looks like from outside perspective. There is a bunch of
development going on. Then devs are "done", and throw the result over to
NetCatters. NetCatters do their unbiased test during their designated
period, and let dev mailing list know about issues. Even if this is not
what we want to happen, this is what the public perceives. NetCat volunteer
sign up had no "dev team" association - was 100% about test suite runs. The
fact that someone from dev mailing list had to "come in" to the discussion
to do some merges based on testers discovery reinforced the sense of
separate offices.

In fact I bet that many of NetCatters do not even know how to code, or set
up build environment, for things they are testing, as they use technologies
(think PHP or database tribe) that are so removed from java desktop
development its infeasible to get started. I remember seeing a discussion
that had issues with developers/testers not knowing how to deal with zip
files, instead of installers. This type of project is a blackbox to most.
I contribute to zend framework and doctrine a few times - I have to fix
issues reported by others because they have 0 qualification to understand
internal architecture.

> When do you plan to do that?
That is what I suggested about removing now obsolete test cases that bog
things down (which I have outlined in Jira) and now propose chunk of netcat
volunteers to do THAT (going through issues, checking if can reproduce etc)
instead of doing yet more runs of those cases. This may be the change that
is necessary after the 13 years now that there are no dedicated employees
to do this.

ср, 31 окт. 2018 г. в 16:49, Jiří Kovalský <>:

> Thank you Alexander and Michal for your feedback. I for one appreciate
> that you spent time elaborating your thoughts in such a detailed
> fashion. I have just two comments.
> 1. Tickets in strange state
> The luxury of dedicated people paid by Sun/Oracle to pay attention to
> bugs, develop features, respond to e-mails and the like are gone. With
> the same argument statement "...the dev team cannot address each
> issue..." makes no sense because there is no dev team. The dev team is
> you. Complaining about issues being ignored equals showing own
> misunderstanding how open source software development works. Good news
> is that you can filter the issues reported in October, trying to
> reproduce them one by one, adding your investigations and setting their
> status and/or priorities correctly. When do you plan to do that?
> 2. Tribe leaders are useless
> I am afraid I disagree. True tribe leaders are precious asset for
> NetCAT. They simply act as managers, communicating with their tribe
> members, finding their strengths/weaknesses, then distributing the work
> load, periodically checking the status/progress, reminding about
> incomplete tasks, triaging issues, escalating the most serious ones to
> the NetCAT program coordinators, organizing meetups, etc. If these do
> not exist, everything falls on plates of NetCAT program coordinators
> which are obviously overloaded which leaves NetCAT participants with
> impression of chaos, ignorance or frustration.
> But maybe I get it all wrong. I was coordinating NetCAT programs only
> for 13 years.
> -Jirka
> Dne 31.10.2018 v 18:02 Alexander Romanenko napsal(a):
> > I want to add to the JIRA ticket problem too. This "tickets in strange
> > state" was discouraging towards the end, because it felt as if testing
> > became just a bureaucratic motion, not really something that lets the
> team
> > know there are issues. Only blocking issues seem to be looked at. It
> leaves
> > with feeling that if the IDE turns on without crashing, thats good
> enough,
> > but whether it actually makes you productive - well thats just personal
> > inconvenience.  This is a bit disheartening, because the UI of NetBeans
> is
> > the best of any on the market. Git presentation is superb, editor
> > splitting, database browser. But there are "small" things like
> > NETBEANS-1373 (related to PSR-4 implementation) or NETBEANS-1452,
> > NETBEANS-1379 which might be "minor" in comparison to IDE doing its bare
> > minimum job, but are a show stopper enough for many to not be able to use
> > NetBeans for actual work.
> >
> > Comments around mailing list or jira like "workaround is to use external
> > tool" or "it works if use 2010 version of the library, therefore not a
> > problem", or no comment at all, as expressed by OP, not only not show
> > whether team has capacity to fix those things to figure out some strategy
> > (maybe advertise on twitter to bounty-hunt those, the same way NetCat was
> > advertised and got me involved), but that no one even cares enough about
> > making the product polished so that I may be encouraged to do some of my
> > own development to help fix those, not just report.
> >
> > Understandably, the dev team cannot address each issue, and what can they
> > even say productively for many of them... But something does not feel
> right
> > when everyone reports their own problems in silence, and there is no
> > process to validate and upvote each other's submissions to be able to
> > signal better what really needs work.
> >
> > Maybe a good use of time could be to not only hammer away at (potentially
> > invalid) test cases, but encourage to go through each other's issue
> > submissions to promote/make visible reported issues to better communicate
> > their impact.
> >
> > Regarding tribe leader - also agree. And the idea that only tribe leader
> > can edit test suites that need to be running I think is wrong. I
> mentioned
> > before and made a Jira issue, there are some test case runs that do not
> > make sense in 2018 or are incomplete to the point that their "pass" state
> > creates a false positive impression. Time was poorly spent on those by
> > testers, when could be used looking at other more relevant places in more
> > detail. But because one must be a tribe leader with all added
> > responsibilities of managing "human assets" in order to fix those up,
> they
> > remain in the list.
> >
> > Regarding time pressure comment. Its not that the time pressuring was not
> > appropriate at all, but it seem to have occurred at odd times of the
> week.
> > Eg. I am assuming that many like myself have some free time over the
> > weekend after work to do this, so getting nagged at random
> > Wednesdays/Thursdays that things are not getting done was misplaced. Now,
> > if after a weekend or two or regional holiday nothing is done, then can
> > start reminding people.
> >
> > ср, 31 окт. 2018 г. в 12:11, <>:
> >
> >> I know that I am nowhere close to make bold statements, but here come
> few
> >> remarks from my side (when it comes to current NetCAT edition).
> >>
> >> There are few things I liked, and few I haven't found quite appealing to
> >> me.
> >>
> >> First of all, I feelt too much time presure. I haven't had this kind of
> >> feelings in the past. It might be that I have joined quite late, but
> still,
> >> there was this rush like feeling.
> >>
> >> I think that people who entered NetCAT might have felt little bit lost.
> >> There was no clear entry point with details how to assign yourself to
> >> tasks. I mean, you could have found all these information, however (in
> my
> >> opinion) it could have been be explained better, pointing directly to
> >> places where you have to click and how to choose stuff. To be honest, I
> >> spent quite some time before succesfully assigning first task to me.
> >>
> >> Just an example, when it comes to slightly missleading info:
> >>
> >> - there is info that you need:
> but then, you are
> >> redirected to version 11
> >>
> >> I think that tests should be more isolated. Pausing, in some cases,
> makes
> >> no sense at all as I had to go through previous steps anyway to get to
> the
> >> point where I have paused.
> >>
> >> JIRA tickets - it looks like we were encouraged to submit tickets, but
> >> they are left in strange state - e.g. there is no person assigned to
> solve
> >> the ticket. After few such tickets, it seems like submitting them makes
> no
> >> much sense. I'd prefer to get - "Not a bug/Won't fix" comment, than no
> >> comment at all.
> >>
> >> It might be, I have missed some sort of memo regarding JIRA tickets,
> and I
> >> need to be more patient - than, it's fine, I will wait.
> >>
> >> Tribe leaders - to be honest, I don't find the concept of tribe leaders
> >> quite useful. The tribes are heavily distributed, and as a tribe
> leaders,
> >> people don't have that much impact on other's work or efficiency. It's
> >> simply more work to do and more to worry about (e.g. distributting the
> >> work). I think I prefer the way it is now, where each person can
> volountier
> >> to perform some tasks.
> >>
> >> Cheers
> >>
> >> Michal
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> For additional commands, e-mail:
> >>
> >> For further information about the NetBeans mailing lists, visit:
> >>
> >>
> >>
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> For further information about the NetBeans mailing lists, visit:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message