SCRUM backlog/sprint backlog per project #1510

@jonasfranz commented on GitHub (Feb 10, 2018):

Could you please point out which features do you especially want?

@jonasfranz commented on GitHub (Feb 10, 2018): Could you please point out which features do you especially want?

GiteaMirror commented

@jxsl13 commented on GitHub (Feb 10, 2018):

In SCRUM you have basically one Product-Backlog, containing User Stories, which are sorted by priority or by some predefined value.
Every User Story consists of most likely a title, description and maybe a name for the value to measure the priority in(more or less like "issues", but sorted by priority) as well as that priority field.
Also a field, which could indicate, whether the User-Story was implemented, removed(because of some issues, not finished or needs more description)

In every Sprint(defined period of time) the devs take some User stories from the Product-Backlog and add them to their Sprint-Backlog, which other than the P-Backlog also consists of (maybe optional) ideas how the developers want to solve the specific problem, which is described by their chosen User-Story. Every developer can see every other developer's assigned user story, but can not edit it (maybe only comment on it)
Devs should be able to only modify their own solution notes, but not the description/title of the user story, thus the need of at least two roles (product owner and developer(not exclusive))
Has dev-1 finished his assigned user stories, he could ask another dev-2 to assign his (other dev-2)user story to dev-1 (well, open for discussions at this point).

Is the sprint finished, meaning the time's up, there could be some kind of overview of the finished user stories and also unfinished ones.
These user stories need to go through two phases.
The finished ones need to go through both phases, one is the Sprint review (e.g. showing the customer the finished improvements)(only finished user stories).
The second phase would be the Sprint retrospective, where the dev team takes a look at what was finished and especially, what was good in the process, and also which user stories were not finished and why not(moving them to the product backlog)
(Maybe some "bulletin board" with information about the definition of "Done", meaning when to consider a user story as done and some process optimization stuff)

Some functionality to kick off a new sprint and maybe based on the normal issue system, the product owner could take these suggestions and convert them into User stories, adding priority, more detailed description etc.

I don't know what would be better, to use the existing issue system and use it as input for the product owner to take from or to use the scrum stuff exclusively, excluding the normal issue system and see the scrum stuff as an own issue system.

TLDR :D
In general there need to be two roles, one being product owner(by default project owner with the possibility to change roles by the first product/project owner) and the other being developers.
Moreover a Sprint is needed, which has a defined(product owner?) duration and some mechanism to kick off a sprint. Kicking off a sprint makes no sense if there is nothing in the sprint backlog, thus the need of a sprint backlog containing assigned(?)(maybe everyone of the devs can change assignments) user stories, which cannot be changed, but commented on(one sticky comment with sub comments?).
Every developer needs to be able(only within a sprint? or whenever he/she pleases?) to change the status of a user story from unfinished to finished (question is, what kind of states can a user story have?)
When the sprint comes to the end, the state of the "issue tracker" should change its state to review phase, only showing finished user stories(And only the sticky developer comment? no comments? all comments?). (What states should we need? : suggestion: planning, sprint, review, retrospective)
Then the product owner(?) should be able to change the state to the retrospective, where maybe the "bulletin board" with suggestions, patterns, good practices, bad practices, etc. as well as well as all, finished and unfinished user stories should be visible again.
After this phase the product owner(?) should be able to change the phase to the next one, planning, where unfinished user stories should(?) go back to the product backlog and finished user stories either archived or deleted(in order not to point fingers at people, when a bug is found afterwards).
And in the planning phase the dev team can can add the user stories again to their sprint backlog.
And after this step somehow a sprint needs to be kicked off, maybe by the product owner.

Have fun discussing(I hope)

@jxsl13 commented on GitHub (Feb 10, 2018): In SCRUM you have basically one Product-Backlog, containing User Stories, which are sorted by priority or by some predefined value. Every User Story consists of most likely a title, description and maybe a name for the value to measure the priority in(more or less like "issues", but sorted by priority) as well as that priority field. Also a field, which could indicate, whether the User-Story was implemented, removed(because of some issues, not finished or needs more description) In every Sprint(defined period of time) the devs take some User stories from the Product-Backlog and add them to their Sprint-Backlog, which other than the P-Backlog also consists of (maybe optional) ideas how the developers want to solve the specific problem, which is described by their chosen User-Story. Every developer can see every other developer's assigned user story, but can not edit it (maybe only comment on it) Devs should be able to only modify their own solution notes, but not the description/title of the user story, thus the need of at least two roles (product owner and developer(not exclusive)) Has dev-1 finished his assigned user stories, he could ask another dev-2 to assign his (other dev-2)user story to dev-1 (well, open for discussions at this point). Is the sprint finished, meaning the time's up, there could be some kind of overview of the finished user stories and also unfinished ones. These user stories need to go through two phases. The finished ones need to go through both phases, one is the Sprint review (e.g. showing the customer the finished improvements)(only finished user stories). The second phase would be the Sprint retrospective, where the dev team takes a look at what was finished and especially, what was good in the process, and also which user stories were not finished and why not(moving them to the product backlog) (Maybe some "bulletin board" with information about the definition of "Done", meaning when to consider a user story as done and some process optimization stuff) Some functionality to kick off a new sprint and maybe based on the normal issue system, the product owner could take these suggestions and convert them into User stories, adding priority, more detailed description etc. I don't know what would be better, to use the existing issue system and use it as input for the product owner to take from or to use the scrum stuff exclusively, excluding the normal issue system and see the scrum stuff as an own issue system. TLDR :D In general there need to be two roles, one being product owner(by default project owner with the possibility to change roles by the first product/project owner) and the other being developers. Moreover a Sprint is needed, which has a defined(product owner?) duration and some mechanism to kick off a sprint. Kicking off a sprint makes no sense if there is nothing in the sprint backlog, thus the need of a sprint backlog containing assigned(?)(maybe everyone of the devs can change assignments) user stories, which cannot be changed, but commented on(one sticky comment with sub comments?). Every developer needs to be able(only within a sprint? or whenever he/she pleases?) to change the status of a user story from unfinished to finished (question is, what kind of states can a user story have?) When the sprint comes to the end, the state of the "issue tracker" should change its state to review phase, only showing finished user stories(And only the sticky developer comment? no comments? all comments?). (What states should we need? : suggestion: planning, sprint, review, retrospective) Then the product owner(?) should be able to change the state to the retrospective, where maybe the "bulletin board" with suggestions, patterns, good practices, bad practices, etc. as well as well as all, finished and unfinished user stories should be visible again. After this phase the product owner(?) should be able to change the phase to the next one, planning, where unfinished user stories should(?) go back to the product backlog and finished user stories either archived or deleted(in order not to point fingers at people, when a bug is found afterwards). And in the planning phase the dev team can can add the user stories again to their sprint backlog. And after this step somehow a sprint needs to be kicked off, maybe by the product owner. Have fun discussing(I hope)

GiteaMirror commented

@jxsl13 commented on GitHub (Feb 10, 2018):

User stories could also have all the properties an issue in the normal issue tracker has, e.g. tags and so on.

@jxsl13 commented on GitHub (Feb 10, 2018): User stories could also have all the properties an issue in the normal issue tracker has, e.g. tags and so on.

GiteaMirror commented

2025-11-02 04:03:15 -06:00

@thehowl commented on GitHub (Mar 3, 2018):

This was already discussed in #805. Personally, I think that workflow of teams may greatly differ, and for this reason we should not have any "projects" feature similar to GitHub's or GitLab's, or the Scrum system of Bitbucket. I don't think there's any viable one-size-fits-all, but Issues are a good compromise for small projects where one can expect not to have a huge amount of things to keep track of.

Gitea unto itself should, as far as I'm concerned, stick to GitHub/Lab-style issues and only provide tools to deal with them using APIs and webhooks, or allow people to use external issue trackers (something we already have!).

@thehowl commented on GitHub (Mar 3, 2018): This was already discussed in #805. Personally, I think that workflow of teams may greatly differ, and for this reason we should not have any "projects" feature similar to GitHub's or GitLab's, or the Scrum system of Bitbucket. I don't think there's any viable one-size-fits-all, but Issues are a good compromise for small projects where one can expect not to have a huge amount of things to keep track of. Gitea unto itself should, as far as I'm concerned, stick to GitHub/Lab-style issues and only provide tools to deal with them using APIs and webhooks, or allow people to use external issue trackers (something we already have!).

GiteaMirror commented

@sapk commented on GitHub (Mar 5, 2018):

@jxsl13 I can recommend you https://github.com/opf/openproject that can work along Gitea. It support multiple workflow and you can setup gitea to use it as your ticket/issue manager (by setting the url in gitea)

@sapk commented on GitHub (Mar 5, 2018): @jxsl13 I can recommend you https://github.com/opf/openproject that can work along Gitea. It support multiple workflow and you can setup gitea to use it as your ticket/issue manager (by setting the url in gitea)

GiteaMirror commented

2025-11-02 04:03:15 -06:00

@jxsl13 commented on GitHub (Mar 5, 2018):

@sapk thanks, looks quite promising

@jxsl13 commented on GitHub (Mar 5, 2018): @sapk thanks, looks quite promising

GiteaMirror commented

2025-11-02 04:03:15 -06:00

@Caballerog commented on GitHub (Mar 17, 2018):

@sapk I've installed open-project and change the ticket/issue manager at Gitea but I've a question, is there any relation between open-project and gitea? or only Gitea link to OpenProject?

My question is because I don't know if there is any way to relation my gitea issues with openproject task (the code of gitea, the same number of issue in gitea and openproject).

Thanks for your reply!

@Caballerog commented on GitHub (Mar 17, 2018): @sapk I've installed open-project and change the ticket/issue manager at Gitea but I've a question, is there any relation between open-project and gitea? or only Gitea link to OpenProject? My question is because I don't know if there is any way to relation my gitea issues with openproject task (the code of gitea, the same number of issue in gitea and openproject). Thanks for your reply!

GiteaMirror commented

@sapk commented on GitHub (Mar 20, 2018):

It maybe possible to link more tightly between openproject and gitea via api but I don't know anyone that as done it (and maybe require some ajustement to gitea or openproject code).
I use it mostly to do advanced project management aside from code hosted in gitea.

@sapk commented on GitHub (Mar 20, 2018): It maybe possible to link more tightly between openproject and gitea via api but I don't know anyone that as done it (and maybe require some ajustement to gitea or openproject code). I use it mostly to do advanced project management aside from code hosted in gitea.

GiteaMirror commented

@exside commented on GitHub (Aug 20, 2018):

I do like the Gitlab approach of allowing to create scrum/kanban "boards" out of labels and turn them into a different view...nothing really changes, it's just a different view, but a very useful one IMHO.

@exside commented on GitHub (Aug 20, 2018): I do like the Gitlab approach of allowing to create scrum/kanban "boards" out of labels and turn them into a different view...nothing really changes, it's just a different view, but a very useful one IMHO.

GiteaMirror commented

@rudineirk commented on GitHub (Aug 29, 2018):

For some teams having an integrated board on the same tool were the issues are created is a must. It would be really useful to have boards like Gitlab or Github has. I was thinkering with the idea of a gitea integrated board/projects tab, and I created a prototype of the idea, it's based on the Gitlab approach:

It's not really working, it's just fixed data, but I think the visual should be something similar to this. The code is here:
https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl

Something that is missing is the visual to create/select boards, like Gitlab has. It would be really useful to be able to create boards for multiple teams.

@rudineirk commented on GitHub (Aug 29, 2018): For some teams having an integrated board on the same tool were the issues are created is a must. It would be really useful to have boards like Gitlab or Github has. I was thinkering with the idea of a gitea integrated board/projects tab, and I created a prototype of the idea, it's based on the Gitlab approach: ![board-some-columns](https://user-images.githubusercontent.com/5260987/44790077-b2da3100-ab74-11e8-99c7-a10d46bc439f.png) ![board-many-columns](https://user-images.githubusercontent.com/5260987/44790082-b5d52180-ab74-11e8-849f-b70ae4ff5d73.png) It's not really working, it's just fixed data, but I think the visual should be something similar to this. The code is here: https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl Something that is missing is the visual to create/select boards, like Gitlab has. It would be really useful to be able to create boards for multiple teams.

GiteaMirror commented

@rakshith-ravi commented on GitHub (Oct 1, 2018):

@rudineirk Were you able to work on this?

@rakshith-ravi commented on GitHub (Oct 1, 2018): @rudineirk Were you able to work on this?

GiteaMirror commented

@tinxx commented on GitHub (Jan 2, 2019):

I would like to see this happen, too! It would enable many small teams to directly and primarily work with gitea instead of struggling with external and possibly hard to set up tools like Taiga.io, etc.
With external tools things like linking commits to issues etc. is likely not possible, that's a huge bonus of this approach! (Being able to just mention the issue ID in your commit to make it appear in the issue/ticket is pretty cool :)

@tinxx commented on GitHub (Jan 2, 2019): I would like to see this happen, too! It would enable many small teams to directly and primarily work with gitea instead of struggling with external and possibly hard to set up tools like Taiga.io, etc. With external tools things like linking commits to issues etc. is likely not possible, that's a huge bonus of this approach! (Being able to just mention the issue ID in your commit to make it appear in the issue/ticket is pretty cool :)

GiteaMirror commented

@ssbarnea commented on GitHub (Apr 15, 2019):

I am really interested about this feature as our team is currently using https://taiga.io/ but the real value is to have an inregrated issue tracker with kanban/scrum planning functionality.

I think that there is a lot of things to learn from GitHub implementation which originally started exactly like gitea. Their implementation is generic enough to allow users to use it for both scrums and kanbans even it it has no idea what a sprint is. If people can define columns and drag and drop cards they will likely find a way to do the planning with it.

@ssbarnea commented on GitHub (Apr 15, 2019): I am really interested about this feature as our team is currently using https://taiga.io/ but the real value is to have an inregrated issue tracker with kanban/scrum planning functionality. I think that there is a lot of things to learn from GitHub implementation which originally started exactly like gitea. Their implementation is generic enough to allow users to use it for both scrums and kanbans even it it has no idea what a sprint is. If people can define columns and drag and drop cards they will likely find a way to do the planning with it.

GiteaMirror commented

@jag3773 commented on GitHub (Jul 30, 2019):

Lodging my agreement here that Kanban style boards would be excellent. No one has yet mentioned Zenhub, which provides several of these features (and more) "over the top" of Github.

Here are the things that I think would be really useful:

Kanban view of issues – this view would be almost entirely a UI, probably would need some DB interaction for tracking the column and order of an issue in a column)
Gantt charts – Gitea already provides issue due dates and dependencies as well as milestones, meaning all the data is there to generate a Gantt chart, I think this would be a really helpful feature. There are libraries like mermaidjs or React Google Charts which would seem to have a reasonable integration cost. Note that #7405 would be helpful for this too.
Organization Milestones – This is probably the easiest to implement, but just like we have the "Issues" (/issues) feature at the top of Gitea, a Milestones feature would be nice. In other words, if I could see all milestones that I'm related to that would be really cool. Currently, I can only view milestones within a single project.

Undoubtedly, each of those would be a feature in their own right. Maybe this combined thread needs split into the individual features/components?

Edit: someone is working on a zenhub like Chrome plugin for gitea at https://github.com/funktechno/git-kanban-enhanced-chrome-extension .

@jag3773 commented on GitHub (Jul 30, 2019): Lodging my agreement here that Kanban style boards would be excellent. No one has yet mentioned Zenhub, which provides several of these features (and more) "over the top" of Github. Here are the things that I think would be really useful: * Kanban view of issues – this view would be almost entirely a UI, probably would need some DB interaction for tracking the column and order of an issue in a column) * Gantt charts – Gitea already provides issue due dates and dependencies as well as milestones, meaning all the data is there to generate a Gantt chart, I think this would be a really helpful feature. There are libraries like [mermaidjs](https://mermaidjs.github.io/#/) or [React Google Charts](https://react-google-charts.com/gantt-chart) which would seem to have a reasonable integration cost. Note that #7405 would be helpful for this too. * Organization Milestones – This is probably the easiest to implement, but just like we have the "Issues" (`/issues`) feature at the top of Gitea, a Milestones feature would be nice. In other words, if I could see all milestones that I'm related to that would be really cool. Currently, I can only view milestones within a single project. Undoubtedly, each of those would be a feature in their own right. Maybe this combined thread needs split into the individual features/components? Edit: someone is working on a zenhub like Chrome plugin for gitea at https://github.com/funktechno/git-kanban-enhanced-chrome-extension .

GiteaMirror commented

@andrewgdunn commented on GitHub (Aug 1, 2019):

@adelowo has a branch over here that people might want to check in on. I'm quite hopeful for what he's hacking on.

I'd love to see more PM type tools make their way into gitea given the simplicity of hosting an instance, however I'd be extremely happy just to be able to do workboards in gitea over the next year or so. I think if people want to hit PM stuff hard they can turn to taiga or alternatives right now and be happy enough.

@andrewgdunn commented on GitHub (Aug 1, 2019): @adelowo has a branch [over here](https://github.com/adelowo/gitea/commits/kanban_board) that people might want to check in on. I'm quite hopeful for what he's hacking on. I'd love to see more PM type tools make their way into gitea given the simplicity of hosting an instance, however I'd be extremely happy just to be able to do workboards in gitea over the next year or so. I think if people want to hit PM stuff hard they can turn to taiga or alternatives right now and be _happy enough_.

GiteaMirror commented

@adelowo commented on GitHub (Aug 2, 2019):

Yup, the diff can be viewed here https://github.com/go-gitea/gitea/compare/master...adelowo:kanban_board?expand=1

@adelowo commented on GitHub (Aug 2, 2019): Yup, the diff can be viewed here https://github.com/go-gitea/gitea/compare/master...adelowo:kanban_board?expand=1

GiteaMirror commented

@genofire commented on GitHub (Sep 12, 2019):

@adelowo when we could see a PR ?

@genofire commented on GitHub (Sep 12, 2019): @adelowo when we could see a PR ?

GiteaMirror commented

@adelowo commented on GitHub (Sep 12, 2019):

In about 8-10 days

@adelowo commented on GitHub (Sep 12, 2019): In about 8-10 days

GiteaMirror commented

@genofire commented on GitHub (Sep 12, 2019):

@adelowo i got a 500 if it try to get localhost/user/project/projects (by your menu):

2019/09/12 10:30:44 ...ers/repo/projects.go:62:Projects() [E] GetProjects: no such table: project

looks like the database bootstrap does not work yet @ version e7cf2b77af

@genofire commented on GitHub (Sep 12, 2019): @adelowo i got a 500 if it try to get _localhost/user/project_`/projects` (by your menu): ``` 2019/09/12 10:30:44 ...ers/repo/projects.go:62:Projects() [E] GetProjects: no such table: project ``` looks like the database bootstrap does not work yet @ version e7cf2b77afe50b5818c52405364faf3c914b9e63

GiteaMirror commented

https://github.com/adelowo/gitea/blob/kanban_board/models/migrations/v95.go

@adelowo commented on GitHub (Sep 12, 2019):

That is weird the migrations are there. Can you run gitea migrate?

@adelowo commented on GitHub (Sep 12, 2019): That is weird the migrations are there. Can you run `gitea migrate`? https://github.com/adelowo/gitea/blob/kanban_board/models/migrations/v95.go

GiteaMirror commented

@genofire commented on GitHub (Sep 12, 2019):

Nothing special shown up:

2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column email_notifications_preference db default is ''enabled'', struct default is 'enabled'
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column passwd_hash_algo db default is ''pbkdf2'', struct default is 'pbkdf2'
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column diff_view_style db default is '''', struct default is ''
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column theme db default is '''', struct default is ''

But:

# sqlite3 data/gitea.db .schema | grep proj
CREATE TABLE `repository` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `owner_id` INTEGER NULL, `lower_name` TEXT NOT NULL, `name` TEXT NOT NULL, `description` TEXT NULL, `website` TEXT NULL, `original_url` TEXT NULL, `default_branch` TEXT NULL, `num_watches` INTEGER NULL, `num_stars` INTEGER NULL, `num_forks` INTEGER NULL, `num_issues` INTEGER NULL, `num_closed_issues` INTEGER NULL, `num_pulls` INTEGER NULL, `num_closed_pulls` INTEGER NULL, `num_milestones` INTEGER DEFAULT 0 NOT NULL, `num_closed_milestones` INTEGER DEFAULT 0 NOT NULL, `num_projects` INTEGER DEFAULT 0 NOT NULL, `num_closed_projects` INTEGER DEFAULT 0 NOT NULL, `is_private` INTEGER NULL, `is_empty` INTEGER NULL, `is_archived` INTEGER NULL, `is_mirror` INTEGER NULL, `is_fork` INTEGER DEFAULT 0 NOT NULL, `fork_id` INTEGER NULL, `size` INTEGER DEFAULT 0 NOT NULL, `is_fsck_enabled` INTEGER DEFAULT 1 NOT NULL, `close_issues_via_commit_in_any_branch` INTEGER DEFAULT 0 NOT NULL, `topics` TEXT NULL, `avatar` TEXT NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL);
CREATE TABLE `issue` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `repo_id` INTEGER NULL, `index` INTEGER NULL, `poster_id` INTEGER NULL, `original_author` TEXT NULL, `original_author_id` INTEGER NULL, `name` TEXT NULL, `content` TEXT NULL, `milestone_id` INTEGER NULL, `project_id` INTEGER NULL, `priority` INTEGER NULL, `is_closed` INTEGER NULL, `is_pull` INTEGER NULL, `num_comments` INTEGER NULL, `ref` TEXT NULL, `deadline_unix` INTEGER NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL, `closed_unix` INTEGER NULL, `is_locked` INTEGER DEFAULT 0 NOT NULL);
CREATE INDEX `IDX_issue_project_id` ON `issue` (`project_id`);

@genofire commented on GitHub (Sep 12, 2019): Nothing special shown up: ``` 2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column email_notifications_preference db default is ''enabled'', struct default is 'enabled' 2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column passwd_hash_algo db default is ''pbkdf2'', struct default is 'pbkdf2' 2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column diff_view_style db default is '''', struct default is '' 2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column theme db default is '''', struct default is '' ``` But: ```sh # sqlite3 data/gitea.db .schema | grep proj CREATE TABLE `repository` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `owner_id` INTEGER NULL, `lower_name` TEXT NOT NULL, `name` TEXT NOT NULL, `description` TEXT NULL, `website` TEXT NULL, `original_url` TEXT NULL, `default_branch` TEXT NULL, `num_watches` INTEGER NULL, `num_stars` INTEGER NULL, `num_forks` INTEGER NULL, `num_issues` INTEGER NULL, `num_closed_issues` INTEGER NULL, `num_pulls` INTEGER NULL, `num_closed_pulls` INTEGER NULL, `num_milestones` INTEGER DEFAULT 0 NOT NULL, `num_closed_milestones` INTEGER DEFAULT 0 NOT NULL, `num_projects` INTEGER DEFAULT 0 NOT NULL, `num_closed_projects` INTEGER DEFAULT 0 NOT NULL, `is_private` INTEGER NULL, `is_empty` INTEGER NULL, `is_archived` INTEGER NULL, `is_mirror` INTEGER NULL, `is_fork` INTEGER DEFAULT 0 NOT NULL, `fork_id` INTEGER NULL, `size` INTEGER DEFAULT 0 NOT NULL, `is_fsck_enabled` INTEGER DEFAULT 1 NOT NULL, `close_issues_via_commit_in_any_branch` INTEGER DEFAULT 0 NOT NULL, `topics` TEXT NULL, `avatar` TEXT NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL); CREATE TABLE `issue` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `repo_id` INTEGER NULL, `index` INTEGER NULL, `poster_id` INTEGER NULL, `original_author` TEXT NULL, `original_author_id` INTEGER NULL, `name` TEXT NULL, `content` TEXT NULL, `milestone_id` INTEGER NULL, `project_id` INTEGER NULL, `priority` INTEGER NULL, `is_closed` INTEGER NULL, `is_pull` INTEGER NULL, `num_comments` INTEGER NULL, `ref` TEXT NULL, `deadline_unix` INTEGER NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL, `closed_unix` INTEGER NULL, `is_locked` INTEGER DEFAULT 0 NOT NULL); CREATE INDEX `IDX_issue_project_id` ON `issue` (`project_id`); ```

GiteaMirror commented

@adelowo commented on GitHub (Oct 1, 2019):

@genofire can you take a look again? I fixed it in 812f256cde

@adelowo commented on GitHub (Oct 1, 2019): @genofire can you take a look again? I fixed it in https://github.com/adelowo/gitea/commit/812f256cdeed312877787b383279c30c5cda9a4f

GiteaMirror commented

@genofire commented on GitHub (Oct 1, 2019):

Works for me, thx - here some small issues:

High Prio:

Move Issues between Boards
add Project to current Issue
view project
create project

Medium Prio:

Projects icon (ATM the same then MergeRequest)
create Issue during viewing project
select project during create Issue

Low Prio:

rename Board
add Board
remove Board
move Board
drop Label | Milestone in beside Search
search for Issue to add them to Project (untested)

@genofire commented on GitHub (Oct 1, 2019): Works for me, thx - here some small issues: --- High Prio: - [ ] Move Issues between Boards - [x] add Project to current Issue - [x] view project - [x] create project --- Medium Prio: - [ ] Projects icon (ATM the same then MergeRequest) - [ ] create Issue during viewing project - [ ] select project during create Issue --- Low Prio: - [ ] rename Board - [ ] add Board - [ ] remove Board - [ ] move Board - [ ] drop `Label | Milestone` in beside Search - [ ] search for Issue to add them to Project (untested)

GiteaMirror commented

@adelowo commented on GitHub (Oct 1, 2019):

Issues can be moved across boards though.

@adelowo commented on GitHub (Oct 1, 2019): Issues can be moved across boards though.

GiteaMirror commented

@adelowo commented on GitHub (Oct 1, 2019):

Thanks for this list. Projects can now be selected when creating an issue. Kindly pull latest

c55d44e023

@adelowo commented on GitHub (Oct 1, 2019): Thanks for this list. Projects can now be selected when creating an issue. Kindly pull latest https://github.com/go-gitea/gitea/commit/c55d44e0233f46094fbebd33feac82e5072e1ba7

GiteaMirror commented

@adelowo commented on GitHub (Oct 1, 2019):

I have submitted a PR at https://github.com/go-gitea/gitea/pull/8346

@adelowo commented on GitHub (Oct 1, 2019): I have submitted a PR at https://github.com/go-gitea/gitea/pull/8346

GiteaMirror commented

@genofire commented on GitHub (Oct 2, 2019):

Issues can be moved across boards though.

does not stored, a reload reset it to Uncategorized

Projects can now be selected when creating an issue.

Does not show list of project

@genofire commented on GitHub (Oct 2, 2019): > Issues can be moved across boards though. does not stored, a reload reset it to `Uncategorized` --- > Projects can now be selected when creating an issue. Does not show list of project

GiteaMirror commented

@adelowo commented on GitHub (Oct 2, 2019):

Hmm, I will take a look again. Let’s move feature discussion to the PR so it is all in one place.

Thanks

@adelowo commented on GitHub (Oct 2, 2019): Hmm, I will take a look again. Let’s move feature discussion to the PR so it is all in one place. Thanks

GiteaMirror commented

@NebojsaKrtolica commented on GitHub (Oct 24, 2019):

zero value comment: can't wait for this to happen, :shipit: 🚀 🍀

@NebojsaKrtolica commented on GitHub (Oct 24, 2019): zero value comment: can't wait for this to happen, :shipit: :rocket: :four_leaf_clover:

GiteaMirror commented

@lunny commented on GitHub (Oct 24, 2019):

Please help to try #8346 and give more advices.

@lunny commented on GitHub (Oct 24, 2019): Please help to try #8346 and give more advices.

GiteaMirror commented

@tinxx commented on GitHub (Nov 23, 2019):

Is there an update on this issue? (It's been a month since last post.)

EDIT: I didn't realize that some people (like @storrgie) could be offended by people being interested in their work. I didn't mean to offend anybody.

@tinxx commented on GitHub (Nov 23, 2019): Is there an update on this issue? (It's been a month since last post.) EDIT: I didn't realize that some people (like @storrgie) could be offended by people being interested in their work. I didn't mean to offend anybody.

GiteaMirror commented

@andrewgdunn commented on GitHub (Nov 23, 2019):

@tinxx you either:

build the PR that is linked just above and provide feedback in the actual PR
figure out a way to financially motivate people to work on this (e.g. contact @adelowo directly for a donation or do something like bountysource to get more eyes on it)

you don't clamor for work to be done when you're not financially or intellectually contributing, that's toxic in open source.

@andrewgdunn commented on GitHub (Nov 23, 2019): @tinxx you either: - build the PR that is linked just above and provide feedback in the actual PR - figure out a way to financially motivate people to work on this (e.g. contact @adelowo directly for a donation or do something like bountysource to get more eyes on it) you don't clamor for work to be done when you're not financially or intellectually contributing, that's toxic in open source.

GiteaMirror commented

@ste6an commented on GitHub (Dec 12, 2019):

Jetbrains just released new version of YouTrack with gitea intergration

@ste6an commented on GitHub (Dec 12, 2019): Jetbrains [just released](https://www.jetbrains.com/youtrack/whatsnew/#new-integrations-with-version-control-systems) new version of YouTrack with gitea intergration

GiteaMirror commented

@genofire commented on GitHub (Feb 11, 2020):

@adelowo any news?

@genofire commented on GitHub (Feb 11, 2020): @adelowo any news?

GiteaMirror commented

@tweinreich commented on GitHub (Feb 24, 2020):

Another suggestion in the meantime: kanboard

It is not exactly an eye candy (out of the box) but it is fast and offers enough features to be very useful.

@tweinreich commented on GitHub (Feb 24, 2020): Another suggestion in the meantime: [kanboard](https://kanboard.org/) It is not exactly an eye candy (out of the box) but it is fast and offers enough features to be very useful.

GiteaMirror commented

@gsantner commented on GitHub (Feb 24, 2020):

Askers: Please have a look at the PR. Seems like it's not so far away 😉

@gsantner commented on GitHub (Feb 24, 2020): Askers: Please have a look at the PR. Seems like it's not so far away :wink:

GiteaMirror commented

@adelowo commented on GitHub (Feb 27, 2020):

Yeah @gsantner . Just a few UI fixes left. Which I should get to this weekend

@adelowo commented on GitHub (Feb 27, 2020): Yeah @gsantner . Just a few UI fixes left. Which I should get to this weekend

GiteaMirror commented

@zuhairamahdi commented on GitHub (Mar 13, 2020):

@adelowo any news on when will this be available?

@zuhairamahdi commented on GitHub (Mar 13, 2020): @adelowo any news on when will this be available?

GiteaMirror commented

@fazlerabbi37 commented on GitHub (Mar 13, 2020):

@zuhairamahdi it is planned to be released in 1.12.0. see #8346 PR for more.

@fazlerabbi37 commented on GitHub (Mar 13, 2020): @zuhairamahdi it is planned to be released in 1.12.0. see #8346 PR for more.

GiteaMirror commented

https://github.com/go-gitea/gitea/pull/8346#issuecomment-617175388

@6543 commented on GitHub (Apr 21, 2020):

Is there any Interest ho have a issue on multible projects and/or boards ?

@6543 commented on GitHub (Apr 21, 2020): Is there any Interest ho have a issue on multible projects and/or boards ? https://github.com/go-gitea/gitea/pull/8346#issuecomment-617175388

GiteaMirror commented

@0xC4N1 commented on GitHub (Oct 30, 2020):

I do like the Gitlab approach of allowing to create scrum/kanban "boards" out of labels and turn them into a different view...nothing really changes, it's just a different view, but a very useful one IMHO.

I'm missing this feature too. Would be great if labels of an issue would update when you move them to different lanes / project boards. Changing labels and thus moving issues between lanes by actionable references in commit messages (i.e. Fixes #1) would be useful too.

@0xC4N1 commented on GitHub (Oct 30, 2020): > I do like the Gitlab approach of allowing to create scrum/kanban "boards" out of labels and turn them into a different view...nothing really changes, it's just a different view, but a very useful one IMHO. I'm missing this feature too. Would be great if labels of an issue would update when you move them to different lanes / project boards. Changing labels and thus moving issues between lanes by actionable references in commit messages (i.e. `Fixes #1`) would be useful too.

GiteaMirror commented