Setup Project for Primerpedia

[Jan-Ka]

Proposal for how to configure the first project for primerpedia.

The way projects are easiest to understand in the context of github is that they are a representation of the existing workflow in the context of a fixed goal.

This goal can be a certain event (like the end of an release cycle) or a timespan (often also called sprint) or a set date.

I'm not sure if this project has any formal "launch" since it's an ever evolving tech demo (as I understand it) so I think the best thing would be to have annual projects. That way older tickets and issue can "fade away".

A Project contains Columns which represent the current state of the managed issue. By convention an issue should usually step through each (or most) columns from left to right. These manipulations are tracked within the issue.

I propose these columns which correspond with a new workflow

1. Preparation
2. Backlog
3. In Progress
4. On Hold
5. Done

Since Issues can be added as Notes into an Project, Column 1 Preparation is to be used for that. Also any Ticket that will be solved within this Project but has to be supplemented in any way should be stored here.

Backlog contains any Issues that remain yet to be worked on in the current Project.

Any issue that is currently worked on needs to be moved into In Progress . While we did not yet have the problem that a issue is worked on by two different developers this will ensure that there is a specific point in time when work on a ticket started. In addition to that this should also go hand in hand with setting an assignee. But I don't think that's possible for non contributors.

Issues that are resolved should finally be put into Done. This can also be used when changing to the next Project.

Additionally to the Columns remains the Topic of Labels. Since we do not use them for anything but the intended use case I do not see any need for change.

Example Picture:

[Jan-Ka]

Before I forget: Milestones can be used to define a Multi-Project Target. Also can Projects be created for specific Tasks that are big enough to warrant it.

[waldyrious]

Thanks for the detailed write-up. I see no problems in using project boards to better convey to users where each issue is in terms of the maintainers' current priorities. That said, I am wary of introducing too much of a formal workflow into this project. I've seen many small projects crumble under the weight of formalism beyond their scale.

So, I'm OK with using project boards, as long as they are taken (by users, contributors and maintainers alike) as informal indicators of project development, to be updated at the maintainers' leisure; and not a process that all issues must follow. And certainly not as

a representation of the existing workflow in the context of a fixed goal [which] can be a certain event (like the end of an release cycle) or a timespan (often also called sprint) or a set date."

Again: I say this not out of laziness on my part (quite the contrary: I'm actually kind of a compulsive organizer, as my frequent cleanups of git history probably makes evident), but out of concern that too much process might burn out the maintainers.

---

I also disagree with:

I think the best thing would be to have annual projects. That way older tickets and issue can "fade away.

As a Wikipedian I'm an eventualist, and in FOSS / hobby projects, I share the view espoused here:

I don't mind stale issues. Honestly, I like them. When a legitimate decade old bug finally gets resolved in an open source project, I'm tickled. Here, all of the ones open I intend to resolve eventually.

Heck, this project was practically hibernated since it was started in 2012, only to come to life once the interest came up. So I firmly say no to (even loose) deadlines and the notion of "decaying" issues that go unaddressed for a long time.

---

As for the columns, I agree with those you suggest, except Preparation, which IMO is unnecessary and could be covered by Backlog or In Progress.

[Jan-Ka]

I'm sure I could have made this more clear that of course this is only an instrument for visualizing (and documenting) the state of the work. Or at least that's what I want to use it for.

It should be tended to in the same manner as we adhere to the rules of contribution (as found in CONTRIBUTING.md). In other words to keep work overhead to a minimum while providing additional benefit to other contributers.

Also I think you got the wrong Idea (again - I should have made that more clear) - since the screen space on the project is rather small (you get like 4 to 5 columns with 10~15 issues each on screen) sooner than later the project will become cluttered and loose it's value in providing information "at a glance"

We can also just remove issues from the "Done" Column after we feel it get's crowded since there is no real benefit of keeping them there. Same goes for Issues in the Backlog. It should contain only Issues that should be favored when deciding what to work on.

But we should not and don't need to invent some hard rules to enforce that, quite to the contrary. If you (as in "the contributer") start work on an year old issue just put it directly into the "In Progress" Column.

I like to use the "Preparation" Column to keep the Notes out of the other Columns since only trackable Issues should be there as I understand them as "proto-issues". As Example - i could have put "Prepare config files for linting" as a Note into "Preparation", which would let you know that this is something I thought of. We could then talk about it and then create an issue from it. I can of course life without them :)

So to summarize: I would like a Project for a certain amount of Issues at a time to see status and progress of the issues. New Issues should be put into "Backlog" of the current Project and Issues that are worked on should be put into "In progress" and finally put into "Done" when a PR has been merged.

[waldyrious]

Ok, I think I understand what you mean better now. I also agree that "Backlog" is redundant with the list of open issues, and so is "Done" (roughly) with the list of closed issues. The "Preparation" column makes sense in the usage you're describing, but I'd prefer* to have such discussions as comments on the issues instead, to keep things in the same place.

I'm more adamant about this latter point than the previous one; if you think it makes more sense to have the "Backlog" and "Done" columns, for now at least, then no objections to use them. But as for the "Preparation", I'd really like to avoid it if possible.

^{* To explain my reasoning a bit better: I think it's already bad enough that git does not provide a native issue-tracking feature that would be independent of the platform -- let's not get ourselves even more dependent on github by using the notes feature which does not currently map to equivalent features in other code hosting systems}

[Jan-Ka]

Hmm, if you put it this way there would be just two columns left ( "in progress" and "on hold") in which case it would be maybe easier to just create a new label "in progress" ?

[waldyrious]

Good point. As long as the final result in terms of information conveyed is the same, I'm fine with that.

In fact, now that I think about it, project boards probably make more sense in larger projects where the usual state of development involves several tasks being worked on in parallel by multiple people, in order to provide a global view of a complex system with many moving pieces. I think it's safe to say Primerpedia does not operate at that scale :)

[Jan-Ka]

Ok, I create an appropriate label.