3

2

Fog Creek likes plugin developers. They're awesome! Anything we can do to help facilitate growth in that community is generally well worth it for us.

Tim asked, "Can we have a discussion page/wiki for possible plugins and related apps for FB?"

If that means a dedicated FogBugz site for you to share (even if just the wiki), or a dedicated SE site... absolutely! Comment appropriately if you want that, and I'll get it done. This hasn't happened yet because we weren't sure it was wise-- FogBugz.SE seems most important. If you just need a front end, you can always use one of our free 2-user On Demand accounts.

There are also things like http://fogbugzplugins.uservoice.com/, which provide some types of feedback and community interaction which StackExchange isn't yet capable of. As SE evolves, it may completely eclipse uservoice for our purposes, but that is yet to happen. The plugin requests poll is an experiment to see if SE can beat out uservoice for our needs... The jury is still out. It's a little awkward that both exist simultaneously.

We haven't taken a lot of initiative on this, since we suspected that a superior way might emerge organically from the community, however we're open to nudging people toward a set of best practices via website text, etc.

So, the question is:

What do you think Fog Creek should do to best strengthen the FogBugz Plugin community?

flag

5 Answers

4

FBOD Approval Process
The approval process for making plug-ins available on FBOD could use some improvement.

The amount of time it takes to get new or updated plug-ins approved and posted is highly unpredictable. I wouldn't mind the wait so much if I had a better idea of what to expect in terms of turnaround time.

Also, there needs to be an expedited approval process for patches to plug-ins that are already approved/hosted on FBOD. A bug was found that didn't adjust dates to the user's local time in my FNN plug-in (it happens) that required a one line fix. However, I wound up apologizing to users of the plug-in for longer than I would have liked while I waited for approval.

Plug-In Gallery
I understand the reasons that the download count is not displayed for a plug-in until it reaches a certain threshold, but if I am logged in as the plug-in author I think it should show me the number no mater how anemic.

It would also be nice for me to be able to see how many FBOD users have enabled my plug-in on their hosted accounts, which isn't currently included in the download counter.

Lower importance, but also useful would be an enhancement to the gallery to allow plug-in users to vote/review/comment on the plug-ins.

Wiki Plug-in API
I'd like to hear from some other plug-in authors on this, but I find this particular API really hard to understand compared to the other parts of the API. Despite releasing a plug-in that uses it, I still feel like I BARELY grok how it is supposed to work I still feel like I am fumbling around in the dark when working with it compared to the ease of the other API interfaces. The half-finished documentation on this part of the API doesn't help much either.

And the obvious
Keep improving the programming and plug-in APIs. There have been a number of plug-ins that I started, but later abandoned because the API simply doesn't yet provide the hooks I need.

link|flag
2 
 Approval Proccess: Agreed. The reason for this is that a plugin with XSS and CSRF vulnerabilities can put all of FogBugz at risk. We're working on a fix for that. We do tend to fast-track plugin upgrades, however, and I attempt to evaluate all plugin submissions within one business day. – Jude Allred♦ Jan 27 2010 at 2:24
2 
 Wiki API: the WikiBlock API is currently under (passive) development. Its priority rests behind that of customer support and core FogBugz improvements, however we completely agree that it needs clarification. – Jude Allred♦ Jan 27 2010 at 2:25
1 
 API Development: This largely happens when we develop a plugin in-house, realize that the API is preventing us from what we want to do, and then fix the API so that we can do it. If you find yourself in that scenario, file a feature request (on this site). We'll see it. In other news, the API will gain some functionality when Kiln releases. – Jude Allred♦ Jan 27 2010 at 2:28
1 
 Re: api development: see developers.fogbugz.com/default.asp?W147 – Jude Allred♦ May 11 2010 at 20:25
2

We at Fog Creek had envisioned that FogBugz.SE could eventually provide you with all that you need-- plugin developers could have tags for their plugins and generally be owners of all questions with those tags, thus providing support, getting feedback, making announcements, etc. This has the advantage of automatically making the plugin community visible to the FogBugz user community. Ditto for general FogBugz ecology.

E.g., I might have a question entitled 'URL Trigger Plugin", tagged 'plugin' and 'plugin-url-trigger', I would keep it updated with the most recent news on URLTrigger, and I could gather feedback on URLTrigger via that mechanism. I'd generally monitor FogBugz.SE for anything containing my URLTrigger tag, and thus gather bug reports and provide support via SE. Some of this behavior has already emerged on its own, such as the 'workflow-plugin' tag, etc.

link|flag
It works for me. – JohnFx♦ Jan 26 2010 at 0:22
2

In the error e-mails that FogBugz sends to the plug-in author when the plug-in throws an error, it would be really nice if it included also the following information:

  • Version of FogBugz
  • FBOD or self-hosted.
  • Hosting platform (DB Server, Web Server, Web Server OS)
link|flag
1

It would be nice to be able to submit a plug-in for FBOD approval directly from the page on the plug-in gallery after you upload it rather than having to send a separate e-mail to request approval.

link|flag
1 
 Indeed. I'll see about adding a link or a checkbox. – Jude Allred♦ Feb 7 2010 at 8:38
0

Do you share customer requests for features that you have chosen NOT to pursue (with related metrics on the request (how many customers, frequency, last asked, etc))?

link|flag
Only in the sense that such requests are usually publically visible on this site or on our discussion boards. Since the advent of SE, we've been creating posts here for nearly all of the feature requests that we get (that aren't already here), and then we consider the SE feedback when we prioritize. I'm not opposed to the idea of a more explicit method of tracking this, however I suspect that we'll continue using SE to provide that functionality if not just for the sake of dogfooding. – Jude Allred♦ Jan 27 2010 at 2:21
1 
 A little clarification... It's fairly uncommon that we flat out choose not to pursue a feature, it's just that it gets prioritized too low in the feature queue to ever get accomplished. We're currently building a system which will allow us to be more transparent with our upcoming features, so that should help plugin developers feel comfortable that we're not about to invalidate their work. – Jude Allred♦ Jan 27 2010 at 2:33
Thanks for the comments. Those are helpful. – Tim Jan 27 2010 at 16:14

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.