We usually have this dilemma in our team.  Sometimes, in order to implement a task or a story we find out that the system must be in a specific state.  For example, a specific system configuration has to be made beforehand.The task / story can be completed and it is working as specified on it with the proper configuration in place.  Note that the configuration is not directly related with the task.Next, we have to create a new ... ??? ... something for the process of generating that configuration file.  This is where the problems appear.  Some say that it is a bug others say it is a task or an extra feature. So, where is the limit between bugs and tasks in the development phase?  Should we even consider something a bug if all the tasks are working as stated in their definitions?  Can a thing be considered a bug because one compares it to the current (unstable) state of the system?Short example:A feature requires configuring a communication service for a specificoperation.In the process of the implementation the team discovers that the service requires the hostnames of the pears to be resolvable to an IP address.The team adds the hostnames to the DNS server (or hosts files) and continues implementing the required feature.After the initial feature is working, a question is risen. Should the sysadmin configure the DNS or hosts file or should our application do it automatically?An automatic solution is possible. So a decision is made to implement it.... here start the discussions ... is this a bug or an extra feature / task?PS: I know that I mixed feature / task / story in the question.  It is intentional.  I am interested in separating bugs from the rest.  Doesn't matter what the rest means in a particular case.
Is it a bug or a task when something doesn't work, yet, in development process
issue tracking;planning;bug report
I would call this a task. If I understand you correctly, it is meant to enable a new feature, so it is not a bug fix - otherwise everything should be called a bug.If the change made by this makes a meaningful difference to end users (independent of the main feature it is meant to support / enable), you may consider calling it a (sub)feature.All in all, no need to agonize too much on terminology, the main point is to get it done :-)