Add start and due date to issue

[kasancode]

Squash #2422

This PR add start date, due date to issue.
This PR will change GitBucket version number because of updating database schema.

If this PR is merged, I will implement gantt chart plugin supporting Future Task.

Before submitting a pull-request to GitBucket I have first:

• read the contribution guidelines
• rebased my branch over master
• verified that project is compiling
• verified that tests are passing
• squashed my commits as appropriate (keep several commits if it is relevant to understand the PR)
• marked as closed using commit message all issue ID that this PR should correct

[takezoe]

Thanks for your contribution as always!

Though this pull request itself looks good to me, I would like to be careful to add new attributes to issues because I want to keep GitBucket core as simple as possible and offload additional functionalities to plugins. However, determining what functionalities should be implemented as core and what should be plugins is not easy stuff.

Regarding due date, the milestone already has it. Of course, I understand the milestone's due date is not enough for real projects. Having start date, due date and even something which represent the amount of work for the issue (e.g. function point) would be useful for the project management. Adding the capability to define custom attributes might be an option. However, it will raise performance concern as we saw in Trac long before.

Anyway, I want to hear opinion from users about this topic. Do you think adding start date and due date is worth to add to issues as a core functionality? Also, do you think we should add further attributes to issues (and pull requests)?

[tlcd96]

@takezoe it depends, right now, the version that i have on my server it's the fastest, it that param is needed, or it's in github, for example, yes, put it.

If this PR is merged, I will implement gantt chart plugin supporting Future Task.

If that plugin will be beneficial for several users, that's great and it should be put in the main, since it's only a param....

[Jookia]

@takezoe GitBucket already includes the ability to assign things, set labels and priorities and track milestone times, so adding due dates lets you prioritize that way too and covers the use case of time-sensitive tasks.

As for adding more fields to core, maybe? It kind of depends on their complexity I suppose. I'd like to have a Bugzilla-type issue blocking system so I can say 'this issue requires fixing A, B, C and blocks E, F, G'

[takezoe]

Thanks for your comments! I want to consider that a capability to add custom fields rather than adding some particular fields. Plugins will be able to leverage this capability to add required fields. As a result of this consideration, if we conclude that supporting custom fields is difficult, we will back to this idea again.

[kasancode]

@takezoe
I understand your concept to keep core system simple. I will follow your decision.

At first, I tried to implement start date and due date in plug-in using issue comment, that has date and text field.
However, start date and due date are useful in some plug-in like Gantt-chart, Kanban, and Calender for example.
So, I thought, these attributes are more suitable for the core system.

[zsmahi]

I think it's a great idea to have this feature; In my case I'm using gitbucket in my company with a lot of plugins (kanban, network plugin) and having this feature will be beneficial for my team 👍

[zsmahi]

Hi , any news about this feature ? is is included as feature or plugin ?

[zsmahi]

Hello @kasancode has this feature been merged ?

[takezoe]

My plan was to add an ability to define custom fields to issues and pull requests instead of adding specific fields. However, this plan hasn't made any progress due to the lack of our development resources.

To be honest, considering our current poor development resources and the difficulty of implementing such a complex customizability, I started feeling that merging this might be more realistic.

[takezoe]

Custom field support is now in progress: #3034