Developer comments
Developer #1: I quite like being anonymous, actually.
Developer #2: It's not anonymous. We are the Developer. You will be assimilated.
Developer #3: My 2 cents:
Often, the developers who comment aren't the ones who would actually implement the things anyway (the ones who implement the most are too busy to look at brainstorm), so you would be contacting the wrong people anyway.
Apart from that, it gives various users the chance to harass developers to implement their ideas / help them / etc if they happen to comment on their idea. This then will make developers less likely to comment, as they know it could lead to a whole lot of unwanted email.
Propose your solution
Attachments
No attachments.
Duplicates
Comments
|
snadrus
wrote on the 5 Oct 08 at 16:00
|
|
|
|
We get so little of their time already. Maybe tie it to a bug report (or similar for features) so there's the consistent communication point.
|
|
ubby
wrote on the 6 Oct 08 at 06:43
|
|
|
|
A good explanation from the developer.
|
|
Auzy
wrote on the 6 Oct 08 at 06:48
|
|
|
I'm starting to like this Brainstorm developer/admin :P
Same guy as before?
|
|
|
You know, I have to ask: how difficult would it be, really, to find out who the developer/package-maintainer is for a given package?
I find Developer #3's argument thus to be specious.
A related question: how does this maintenance of develper anonymity foster the principles of the Ubuntu Community of Conduct?
|
Hobbsee
(Ubuntu developer)
wrote on the 7 Oct 08 at 13:26
|
|
|
Chipbennet:
How difficult would it be? Not very. Aptitude even provides an interface on it. The question really is "how many users will look that information up, and use it?"
My suspicion? Not many. Or at least, the ones that do will probably approach developers after more consideration (such as "ubuntu releases in under a month, perhaps I shouldn't ask for features right now")
|
|
|
@Hobbsee: but, isn't that where all these initiatives should be headed - that is, more transparency between the distribution, the developers, and the users?
Personally, I think that the same users that would contact a developer through a Brainstorm link would, if such link weren't available, find the contact info in Aptitude, LaunchPad, or wherever.
Of course, that transparency - that interaction between distribution, developers, and users - should be guided by the Code of Conduct. (As in your example: anyone asking for a new feature within a month of a distro release is clearly not following the CoC principle to Be Considerate.)
|
|
|
I work for a software development company that was bought up by another software development company. With that said, the initial company has their developers available to work with the support people. The idea being support has a problem, the developers created the application, they know how things should work and when they don't, how to fix it.
The new company has their developers locked up in a little room away from support. In fact, support couldn't talk to development at all until recently for help with an issue. The idea being, they have too much too do to spend time talking to support.
Ultimately, I think developers need to work with people supporting the product, but not necessarily with the end user. I Agree with the comment above that if they posted their names, people would be contacting them about everything. Regardless of it is related to the fix they helped create or not.
My two cents.
|
|
Hobbsee
(Ubuntu developer)
wrote on the 2 Nov 08 at 12:31
|
|
|
Of course, that transparency - that interaction between distribution, developers, and users - should be guided by the Code of Conduct. (As in your example: anyone asking for a new feature within a month of a distro release is clearly not following the CoC principle to Be Considerate.)
Well, that's the question, isn't it? A lot of the time (and the recent bug about upgrading ekiga is a great example), a user will want something ZOMGNOW, says it should delay the release, etc, etc, etc, with (apparently) no concept of the idea of freezes and testing (and lack of properly installable packages!). The package in question required a whole lot of other packages to be upgraded, which was in turn going to effect other packages, and wasn't something the Release Team wished to play with a couple of weeks before release.
Is it fair to tell them off for breaking the code of conduct, for not knowing / thinking about development procedures? That seems a bit of a stretch to me (and sure to have false positives, etc).
I agree in theory with your comments - but I think it's very important that the development areas are kept as development areas, and don't turn into quasi-user-support / soapboxing / etc, because it would be very easy for development to be disrupted, regularly, due to the user support / soapboxing / random ideas in there / etc.
It's definetly a balance!
|
|
andruk
(Idea reviewer)
wrote on the 8 Feb 09 at 19:45
|
|
|
Developers should be able to ignore people who hound them.
They do need to be held accountable to the Ubuntu Code of Conduct, and I think anonymity doesn't help this.
|
Post your comment
|
