Tag Info

Hot answers tagged

44

This is a dilemma: you cannot close the issue as "fixed", because you don't actually know if it was fixed, or at least even if some issue was fixed, you don't actually know whether this was the issue the reporter was talking about. On the other hand, you don't want to leave an issue that might have been fixed open, especially if you won't ever be able to ...


10

Your main question was already answered, but you also asked about documenting the process and that needs answering too. The solution I've seen in many projects is not to put it in the project's README.md, but in a special contribution README - a README file for contributors. This file describes everything you want the people contributing to your project to ...


7

I read this as more a question about the practices around how to handle an unverified bug (using github's issue tracker) than anything else. To me, that is a rather straight forward answer based on other issue trackers I have used. Github doesn't force anyone to use any workflow and this makes it very flexible... and rather useless in its default ...


4

The term "backend" is not offcially defined, so there is no "real" backend. For example, in my current working context, I would call the database a backend component (even if it does run on the same machine, maybe embedded in the program's process), but not a "data access layer". So my suggestion is whenever you use the word backend, give a clear ...


3

I would take one of two views, depending how confident I was that I was talking about the same thing as the original reporter: 1) Since the reporter is no longer available, deem that the bug in question means whatever it was you fixed. If it helps, attach test cases to make clear what failures you found. Describe in detail on the bug report what it was you ...


2

The important thing is to develop an open, transparent and trusting relationship with the client. The customer needs to understand what your challenges - and cost - are to work in the manner you are being forced to work in. At the same time, you need to understand why is it that the client cannot deliver in a predictable manner. Once there is appreciation ...


2

Well... this happens all the time, and going agile is not going to fix the issue, rather you could get the web service definitions / contracts finalized. At this point you could actually start to build your system with mocking of the client web service using some tool like SOAPUI. Once the customer service is up and running, you can actually test it. Of ...


1

This is because "backend" can mean a lot of things. Without context it has no meaning. For instance: In a CMS it is not uncommon to actually call the administrative interface "the backend". Try a search for "Wordpres backend." and you'll see what I mean. Wikipedia list of front and back ends



Only top voted, non community-wiki answers of a minimum length are eligible