Tracker issues continued
EAP'ers,
Most of you know about the various problems we have with the tracker and
the way we use it for collaborating with our community. The biggest problem
with bug and feature requests is that they get posted to the tracker without
being discussed beforehand which often leads to poorly formulated, impossible
to plan, hard to follow, etc issues. Given the size of the community and
the amount of features in the product, this becomes a very hard task to maintain
in real time (which is the real value of the tracker actually).
We have the following idea: we restrict the write access to the tracker to
a limited amount of EAP'ers. This team of people is elected by the EAP community.
These people will be able to submit/modify issues in the tracker and help
us do the work for maintaining the tracker in the state of order. We will
create two discussion forums dedicated to bugs and features where all those
should be posted, discussed, refined and made up as useful requests that
are possible to use for planning and implementing features and fixing bugs.
And of course, this does not concern exceptions, they will get submitted
by anyone as before.
Therefore, if you are willing to help and would like to be the one with the
write access, please send your name to Max Shafirov at max (at) jetbrains.com.
We will make up a list of all submitted names and create a poll for all
of you to vote on those 10-15 people who will make up this team.
We hope you understand, let us know if you have any other questions.
Best regards,
Eugene Belyaev
President, CTO
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
请先登录再写评论。
As Rob correctly mentioned, the biggest problem we have here arise from using
a single tracker for doing both things (external interface and internal planning
and development tracking software) which, after a specific volume and quality
become hardly manageable and useful. Having two systems is actually exactly
what we've been discussing here some time ago. One thing that stopped us
is the additional hassle requiered for maintaining two projects and watching
carefully interlinks between them. JIRA is well suited for our internal
needs. Our old tracker is good at some things (mostly external) but it requires
a lot of maintenance and pretty hard to integrate with JIRA (in case we use
different systems). Software is not perfect and we did not find a relatively
good way to link the two trackers. But maybe it is still worth doing, what
do you all think?
Best regards,
Eugene Belyaev
President, CTO
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> In our bug system, we have a 2 tier mechanism, but the 1st tier is an
>> "event' system.
>>
Interesting. Could be a voluntary sign-up type thing where anyone
interested can sign up as a 'moderator/whatever'. Casual users won't
bother, only those genuinely interested. Community guides quality. Very
Wiki-like. I would go for that.
--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Eugene Belyaev wrote:
>
I agree it's worth doing, for all the reasons mentioned by many people
in this thread.
JIRA is too heavy, too complex to accomodate an EAP community like this one.
Alain
Eugene,
I may be off here, but what if you use Confluence? People could open up
discussions in confluence and if something is deemed an issue to be
escalated, then the group/JetBrains moves it to Jira. People would not
be able to file bugs directly in Jira.
R
In article <unit-065106552632412317329654220@news.intellij.net>,
Eugene Belyaev <beg@jetbrains.com> wrote:
What are some of the issues involved in managing
the links between the two systems? I would think
that in JIRA, we would add a field (I'm not familiar with
JIRA, but I assume it allows that level of customization)
that contains a link to a tracker "event" and a
brief description by the person who did the linking.
Ideally, that field could be queried automatically by
tracker (or something that sat outside of both)
and place a back-link in the tracker event to indicate
that an event is covered by a specific problem or task.
So, the work process would be volunteers identify that
an event is really this more complex/larger task/problem
and cut and paste the tracker entry into a JIRA
field.
Subsequent to that, a query is run, and the tracker entry
changes state and establishes the back-link (my assumption
is that it is easier to customize tracker to do
fancy things, then it is to customize JIRA).
Is something like this doable?
Mike
While SKelvin's response seems a bit extreme, it is definitely my initial reaction too.
Over the last 3 years, I've probably put in 2 dozen bugs. While I've attempted to make good bug reports, I know that sometimes I hit and sometimes I miss. I'm definitely not a professional QA engineer, and it definitely shows in some of my bug reports.
The reason why you get bug reports from me is because the process is "friction-free". I don't have to go through a committee. I'm a pretty busy guy these days, and I don't really want to spend 2 or even 3 posts convincing someone that the problem I entered is a problem.
The first time some discussion group moderator asks me "are you sure" or "did you remember to clear your cache", I'll have to become irritated with them. Will this cause it to be the last bug I ever enter? Probably not. It will definitely decrease the number of bugs that I enter significantly. If this causes bugs to go unnoticed and unfixed, it won't be long until I lump your product into the "too buggy to love" category.
Any decision JetBrains makes is obviously up to you. I urge you to consider this choice really carefully though. I believe that part of the reason why you guys have done so well is good vision and smart programming. Another part though is your community. We provide you with an enormous number of projects to test IntelliJ with. Ours are live "real" projects that evolve as our own products evolve. You can never reproduce that in the lab.
You might respond that you'll still be accepting bug reports, just in a different way. Every barrier that you erect between your community and submitting bugs will have the effect of reducing the number of bugs that are submitted. Perhaps you'll get rid of some duplicates, but you'll probably lose a lot of good bugs too.
I'm guessing if your plan doesn't work correctly the first time, your community might take a hit that you aren't prepared for. I can only hope you don't make a decision that will cause the ultimate downfall of your product.
-Matt
Don't you have to do that already? If you submit a bug and someone from JetBrains can't readily figure out what's going on, it will change the bug state to "More Info Needed" and you'll get a message asking for a little more information, like "did you remember to clear your cache?".
To the end user (the bug reporter), little would change. They would still be reporting bugs, and having someone taking a look at the report. The only real change is on the jetbrains side: they would have more people that are supposedly familiar with IDEA and can pinpoint common errors and feature requests. Weather this would really affect the reporter experience lies on the person that would be screening the issues: IDEA should choose them very carefully.
Actually, I get irritated quite a bit. I get requests like "more info required", and then I ask additional questions about the nature of the problem, and how they want the information, and it falls into a big hole. I would prefer it if the community would lead individuals to a point where the problem was fully understood and reproduceable.
That would probabaly be the most value. If I am coding along, and something weird happens, but I don't know how I got there, it is of little value to JetBrains. These events would be the kind that would be screened.
Obviously exceptions would still need to be handled by jetbrains because of the obfuscation and knowlege of the code required to understand the report.
Mike
Rob Harwood (JetBrains) wrote:
Jira can be set to a "closed" system where only the admin users can
create users, as opposed to joe-random-sign-up's which could be useful.
Also, users can be assigned into the "user" or "moderator" permissions
scheme.
Once a good setup of permissions and workflow is setup it should be
possible to do all we need.
Eugene Belyaev wrote:
Eugene - for what it's worth, and I'm not sure if this small feature
will make a difference, but one additional feature in Jira Enterprise
over Professional ( which I'm running here at work ) is that you can
have issue-level security.
Wheras in professional if I have access to a project, I can see ALL
issues in that project, with issue level security, I may have access to
the project, but I can only see/query those issues I have access to.
So alot of the internal planning/tracking issues that JetBrains use, and
don't particular want us pleabs to see, can be limited off.
Have you guys spoken to Mike and Scott at Atlassian about some of the
issues you guys are presenting here?
Mark
I'm overjoyed when a JetBrains employee says they need more info from me -- it means my problem is being looked at. I know it doesn't mean that it is necessarily going to be fixed, but at least I know it is being looked at by the right person.
Your second point is really important though -- who they choose as moderator is immensely important. If it is easy enough that 10-15 part time moderators could do they job, why not just hire a couple of full-time employees to do the same job? Then there is absolutely no change to me. Also, I don't have to worry about the motives of volunteers.
In article <17023079.1105649891842.JavaMail.itn@is.intellij.net>,
Matthew Flower <no_mail@jetbrains.com> wrote:
For the same reason there isn't a full fledged QA department, and the
EAP serves as a serious QA process. This allows them to keep costs low.
The more folks they add, the more they'll likely need to charge for the
software.
R
Hi All,
Haven't been following jetbrains.intellij.eap for a while...
This is BY FAR the craziest idea I have ever read in this newsgroup.
Friendly,
Dmitry
--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop With Pleasure!"
Which is sufficient proof that you really haven't spent much time among us...
Hello Dmitry,
Interesting... Omea reader shows this message as a direct reply to Eugene's,
so I don't really get it: are you trying to get fired, or what? :)
Andrei
Hello Marcus,
>> This is BY FAR the craziest idea I have ever read in this newsgroup.
>>
Not anymore... But I have had my days.
Friendly,
Dmitry
--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop With Pleasure!"
Hello Andrei,
>> Hi All,
>> Haven't been following jetbrains.intellij.eap for a while...
>> This is BY FAR the craziest idea I have ever read in this newsgroup.
Trying to keep the company afloat :)
Cheers,
Dmitry
--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop With Pleasure!"
Hello Dmitry,
Do you have better ideas?
That's true, you need to get back to us. Not crazy enough to join the Burning EAP Legion anymore?
Hello Dmitry,
I think I do. I have not had time to read this thread thoroughly, so pardon
me if I reiterate some of the thoughts that have already been discussed.
Then again, I am not in the IDEA team anymore, and I have not discussed anything
that follows with them, so these are only my opinions, and I can be dead
wrong of course.
Anyway..
Much as I respect enormous contribution that many of old-time EAP members
had given to success of IntelliJ IDEA, and much as I value their opinion,
I firmly believe that the steering wheel for IDEA must be held firmly by
IDEA team and JetBrains in general.
Adding a community filter takes much of the guidance for that steering wheel
out of reach of IDEA team.
Also, I believe that by opening EAP for our product we at JetBrains make
a promise: to listen to our EAP members, to value their opinion, to talk
to people. We get enormous help from the community, so we must not break
this promise.
I firmly believe that implementing the idea that Eugene proposed actualy
breaks that promise. The EAP member talks to, and is litened by, another
EAP member, not someone from JetBrains, the actual steering-wheel holder :)
From the beginning, our EAP also possesed a very nice feature. EAP members
who submitted a bug/feature have had a direct contact with developer responsible.
This was incredibly cool for the product of this size and user base, and
this is something we all would hate to loose.
However, it is just a nice feature. It have never been in any written or
unwritten promise, and in fact ceased to work for some time (due to enormous
amount of SCRs etc.)
So, in my opinion, it will be right and correct to have a dedicated IDEA
team member(s) who will just process incoming SCRs.
Thus:
a. The control on SCR policy is still firmly within JetBrains.
b. EAP members talk to someone from JetBrains
c. SCRs are processed much more promptly.
Call that guy "EAP PR Representative for IDEA team" :)
I am not sure this is going to work well. Maybe this can be refined somehow.
I just have a gut feeling that Eugene's proposal smells wrong and is not
the right direction to go at all - for the reasons I tried to spell out above.
BTW, AFAIU this is the way it works at the moment in the IDEA team. Do you
feel it is better? Worse?
Friendly,
Dmitry
P.S. Oh the good old days :) ReSharper EAP newsgroup is not like this at
all (yet?). I miss heated debate, whining and praise!
--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop With Pleasure!"
Ok replying to myself is bad, but it just occured to me that the better title
will be "EAP Product Manager".
This difines his/her role much better.
Cheers,
Dmitry
--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop With Pleasure!"
In article <4961843.1108833016673.JavaMail.itn@is.intellij.net>,
Marcus Brito <mbrito@gmail.com> wrote:
We are not for the faint of heart or those who get offended by mere
mention of their name in the context of a donut. :)
R
Right on Dmitry!
Of course many of us view the 'good old days' with rose tinted glasses, but there's a significant number of people who have been distinctly unimpressed with 4.0 onwards, and I suspect a big part of that was the democratisation of the EAP process. Somewhere along the way, the users ended up deciding what features IDEA should have, rather than the IDEA guys themselves.
So the current proposal of giving these (frankly, idiot) users even more power seems a bad idea. Users do not have the insight into IDEA customers that IDEA developers do. They just see their little piece of the world and their crappy little needs. All relevant of course, but not sufficiently so to dictate what gets worked on and what doesn't.
So we're led to the current situation, where there is far too much user participation, with the end result that those who yell loudest have their voices heard, and those who have valuable feedback but aren't interesting in a yelling contest driven off because they have better things to do with their time.
I don't think it's even a matter of hiring more people, but instead, as Dmitry suggests, converting more of the existing team's time into SCR management. Instead of each dev having to do it for one day a week, have it be more often.
Alternatively, don't give the same weight to halfassed random ideas raised as SCR's. Far too much content is wishful whimsy. You guys decide the features, we (the EAPers) tell you how well they work.
I too remember the glory days, and I don't think we are that far from that. But in the glory days, I remember Eugene or Valentine announcing large, sweeping ideas, and then asking for user input on those ideas. I remember developing basic concepts of editing, browsing, and developing code.
I think these are the ways in which the user base (even though it is larger) can still participate. It isn't about deciding whether a new option is added, or whether it is sticky (yes, these things are important).
But it is gaining the sense that you are helping contribute to a new way of developing code. A new paradigm.
Perhaps IDEA releases should have a series of themes. And the best time to touch base with the user comunity is in developing a comprehensive view on what those themes will mean to the different ways in which we use IDEA in our day-to-day work.
Sometimes I feel that the only way I can still contribute is in pressing the send button when an exception is raised, and offering the ocasional missed attribute as a new feature.
I hope right now Jetbrains folks are asking themselves "What's wrong with software development today...". And perhaps we can help expand on whatever creative answer they come up with.
So what would this look like?
I would expect that IDEA developers would post early versions of the roadmap (perhaps in smaller chuncks with more intent behind the feature lists). Lively discussions would ensue about how different people would use the features, and whether or not this would be useful to have.
As always our Jetbrains friends must take our rantings with a a grain of salt. We are only a small community out of a very large user base, and their business decisions are theirs alone (let us not forget the whole AspectJ thing).
Then the official EAP would start (after suitable development of course), and we would provide our normal feedback in the course of development.
Mike
Dmitry Lomov (JetBrains) wrote:
While I agree that IDEA is better off with the IDEA team deciding the
features, I have noticed that some JetBrains developers do not fully
respect the input of the users and EAP members. I remember talking with
one developer who said something to the effect that 'none of the
important features of IDEA ever came from the EAP community'. I really
think that is short-sighted thinking, and was shocked to hear that.
Please be aware that I'm not talking about all the developers, or even
a majority. I'm not even talking about Dmitry Lomov, even though I'm
replying to his post. But I have noticed that this attitude is present
among some developers, and I would like to see it diminish. It is a
foolish attitude, in my opinion.
Here is what I think makes IDEA great: 1) Visionary features 2) polished
to a sparkling brilliance by the user community.
If all we had were visionary features without any polish, IDEA would not
be anywhere close to what it is today. Don't believe me? Read _Crossing
the Chasm_ by Geoffrey Moore.
You can come up with a great invention, but if it's hard to use, fails
at simple tasks, requires a lot of preparation, has a steep learning
curve, is too late in development, or is hidden away where no one can
find it, then some other competitor will fill in those gaps and you can
say bye-bye to your invention.
We are experiencing this competition right now, and its name is
Eclipse. The only thing holding us up is our superior product. However,
it is nearly inevitable that Eclipse will end up dominating the IDE
space for Java (even if IDEA remains technically superior). The question
is when, and how much it will hurt IDEA and JetBrains. If we lose sight
of what makes our products superior, that time will be soon, and the
pain will be very big. Don't believe me? Read The Innovator's Dilemma
by Clayton Christensen.
So, back to the whole tracker thing. Obviously, the old tracker was
broken. Too much unstructured, unfiltered user feedback. However, the
problem is not the user feedback itself. It is that the feedback is
unstructured and unfiltered. Whatever the solution is, it should make it
easy to give feedback, and it should have a system for filtering and
structuring feedback. The problem is not that the EAP has been
democratized (in the sense that anyone is allowed to give their
opinion), but that the important voices are drowned in the noise.
I think having one person, Product Manager, or EAP Liaison, whatever you
want to call it, in charge of communicating with EAP members and keeping
on top of things, is a good idea. It would be great. I think we need it.
But I don't think it would completely solve the feedback problem. What
it would do is introduce a bottle-neck, where everything has to go
through one person. That would discourage feedback in general, or at
least reduce the efficacy of feedback.
I think the EAP community needs more control over the steering wheel,
not less. However, there would be two steering wheels. The vision wheel
driven by JetBrains, and the polish wheel driven by EAP. The
liaison/product manager can help make sure both wheels are pointing in
the same direction.
The discussion regarding ways of giving more control to certain members
of the EAP community (to help with structure and filtering) is going in
the right direction, I think.
</rant>
--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"
I couldn't agree less with this. IDEA has the polish that it has because the EAP members (and the community in general) uses IDEA for a much, much wider range of tasks than JetBrains could ever imagine, and provide feedback about what works, what doesn't, and suggestions for more. I've seen some great suggestions for new refactorings, for example. Maybe they're things that JetBrains would never have thought of. They're things I hadn't thought of, but I can immediately see how useful they would be.
Hello Rob,
>> Much as I respect enormous contribution that many of old-time EAP
>> members had given to success of IntelliJ IDEA, and much as I value
>> their opinion, I firmly believe that the steering wheel for IDEA must
>> be held firmly by IDEA team and JetBrains in general.
>>
>> Adding a community filter takes much of the guidance for that
>> steering wheel out of reach of IDEA team.
>>
Right on Rob. You've got my idea perfectly. EAP Product Manager should play
the EAP
card inside IDEA team (read up on XP practices to read about the role of
Product Manager in )
--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop With Pleasure!"
Hello Rob,
I an afraid you misread my post completely.
I am in no way diminishing the EAP role in IDEA success.
You need to quote no one to make me aware of EAP enormous contribution -
I experienced it in my work on IDEA myself.
What I say is that Eugene's idea - limiting write access to tracker - hurts
EAP community.
A car with 2 steering wheels gets nowhere, no matter how much sychronizing
is applied.
My idea was that EAP Product Manager will be playing EAP card inside IDEA
team, making IDEA developers more aware of what EAP actually need. Read up
on the role of Product Manager in XP development process - I meant 'Product
Manager' in that sense: someone who represents the customer (EAP in our case)
inside the team.
My point was that this person should be an insider, should be someone from
JetBrains, not someone community elects, not even someone we choose from
community.
Friendly,
Dmitry
--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop With Pleasure!"
Dmitry Lomov (JetBrains) wrote:
>>
I did not misread your post. I specifically said I wasn't talking about
you. However, in your comment which I quoted, I was reminded of a
certain conversation I had where a JB developer gave his opinion that
EAP wasn't very valuable. It was your comment that 'a community filter
takes much of the guidance for that steering wheel out of reach of IDEA
team' which reminded me of this conversation. I'm sorry that I gave you
the impression that I was talking about you. I should have been more
clear about that.
With that in mind, I don't think my rant was pointless. You are of
course free to disagree if you like.
Looking back at Eugene's post and other discussions, I seem to recall
that we were talking about having one tracker group that everyone could
write to, and a small subset of the community that would have more
control, such as being able to promote issues or change their state,
etc. I don't think Eugene was actually talking about restricting all
write access to only a small group of EAPers. Perhaps someone could
clear this up. Maybe I've got it wrong; I haven't been using the EAP
version and haven't tried the new JIRA groups yet.
>> I think the EAP community needs more control over the steering
>> wheel, not less. However, there would be two steering wheels. The
>> vision wheel driven by JetBrains, and the polish wheel driven by EAP.
>> The liaison/product manager can help make sure both wheels are
>> pointing in the same direction.
I guess I'll have to disagree with you there. It's a metaphor anyway. My
point is that there is no single steering wheel. The metaphor of
steering wheel is inherently flawed; it forces us to think about a
single point of control.
In any project, you have multiple points-of-view and you need to balance
them all depending on their importance. With IDEA, we need to balance
vision and polish. That's the point. I don't think a single gate-keeper
role can adequately handle that. There is too much feedback to keep
track of for one person, and the compromise will end up being that some
good feedback is ignored. I think making the EAP more self-regulating
and self-organizing would help keep the feedback manageable.
Certainly such a person would be very useful to the team, and also to
the EAP members. I think it's a great idea. I also think giving the EAP
members more power to self-organize is a great idea. Of the two ideas, I
think the self-organizing EAP is more important, because it directly
addresses the issue of polish.
--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"
During the day I'm a professional java programmer. During the night I'm a die-hard MMORPG[/url] player (don't ask me how do I find time to do both things, it's a mistery), and the MMORPG companies and players face a situation very similar to what JetBrains and EAP users are facing right now.
Massive Multiplayer games are driven by continuous changes and community feedback. The makers need to listen to the players, realize what they want and develop it. Managing this process (gathering feedback, filtering and deciding what gets implemented, and how) isn't easy, and we all know that.
The most used solution in the game world is exactly the same Dmitry is proposing, just with a different a different name: Community Manager. The community manager is in charge of listening to feedback from the players (usually entered in forums[/url] run by the game company), and translate that into concrete actions inside the company. The CM is also responsible for the other way around: telling the community what the developers are doing and what kind of info or feedback they're currently looking for. This seems to work,
Does it rings a bell? Yes, it's very similar to what we do here, except we don't have a community manager; the users communicate directly to the developers. This doesn't scale, and that's exacly why we start this thread in the first place.
Long story short, we could really use someone from JetBrains who's in charge of managing the community. Someone whose job is to read the forums and answer our posts, go to the issue tracker and manage our requests, to discuss with the developers what we're looking for, and tell us what they think about it.
</rant>
20 more minutes until I take off and go home to play WoW...