Organizing Unity8 work
-
If people are to get involved then everyone (not just devs, or an "in crowd") must be able to see the the workflow (and status of work items).
The essential things to show "at a glance" are a "wishlist", a "backlog" a "in progress" and a "complete". Work items are ideally a day or so's work, but that's only essential once they get to "in progress". Also important in "in progress" is who's doing it and how to contact them about it.
There are tool that aim to make this easy, but my experience is they make doing wrong things far too easy. You need discipline to use them effectively. I suggest a simple Wiki page like this:
Finished
Demo Unity8 running on 18.04. Requested: @mariogrip. Developer: @mariogrip
...In progress
Test Unity8 running on Fedora 27. Requested @alan_g. Developer @DanChapman
Refactor USC "Miral style". (Split from "Rework usc to use miral"). Developer @WebDrake
...Backlog
Get Mir running on Debian sid. Requested: @mariogrip.
Rework usc to use miral. (Split from "Wish all out components used miral")
...Wishlist
Integrate Unity8 with GDM [blocked by Mir]. Requested @alan_g.
Wish all out components used miral. Requested: @mariogrip.
...
The rules are as follows:
-
here's a low barrier to putting ideas, feature requests, bugs and other stuff into "wishlist".
1.1 The description should be short, with a link to more information (GitHub issue etc) if needed.
1.1 Anyone with an interest in the project can put things into "wishlist".
1.2 The requestor should put their name against it in case of questions and to verify the result.
1.3 Things can be removed from "wishlist" if they are unsuitable. -
There's a regular review meeting that decides what we want to do now and maintains "wishlist" and "backlog".
2.1 Items moved from "wishlist" to "backlog" may be rewritten to clarify.
2.2 Items in "wishlist" may have smaller items split out of them for "backlog".
2.3 Backlog is ordered with most desirable at the top. -
When someone is able to tackle work they take the first item from backlog they feel qualified to tackle.
3.1 They should check their understanding of the problem the item solves with the requestor and move it to "in progress" adding their name.
3.2 "In progress" covers investigating the problem, coding the solution, and getting any code approved and merged
3.3 If the item seems too big then they can propose a split and put the resulting item into "In progress". -
Work is not "done" or "finished" unless it is verified (by the requestor or similar) and on master.
4.1 Things can be removed from "finished" when they ship in a release.
Work items ought to be around a day or two's work. This can be relaxed for "wishlist" but should be stricter for "In progress".
If you abandon work on something "In progress" be polite and put it back in "Backlog". -
-
Hi Alan,
Does this meet what you're looking for in this regard? https://github.com/ubports/unity8/projects/1
-
@unisuperbox not bad, but not quite how I envisaged it. (But it isn't me that has to work with it!)
Important differences:
- The distinction between "wishlist" (someone wants it) and "backlog" (we aim to do it soon) matters. Calling one "To do" is fine, but there needs to be two lists.
- "In progress" doesn't show who's working on it.
Other differences:
3. I dislike the word "Done" as a status - it ought to mean "in use by the end user", but too often means far less. E.g. "awaiting initial feedback from qa/reviewers" -
I would add that the backlog description, so after the review meeting by the experts, should contain indications about the Programming languages and the task difficulty .
also what about adding micro-tasks and some mentoring so to help train some new developer (ala LibreOffice/Document Foundation )? -
Hi @alan_g -- good to see that there is a renewed push in this direction. Recent times have been a bit busy but I'll try to reawaken the USC-on-MirAL work soon. IIRC it's a bit in need of feedback/advice now.
In the short term, would it be convenient to try to rework that as a GitHub PR against UBPorts repos?
I've recently updated a machine of mine to the latest Ubuntu daily releases (18.04 to be) and added the UBPorts Unity 8 PPA. What's striking about that is that it seems much less stable/reliable right now than the Yunit PPA on top of xenial. The latter seemed pretty stable when apps running directly on Mir were being used (only XMir-using apps seemed problematic), but the new UBPorts packages seem to have some quite unpleasant getting-locked-up/crash-y behaviour even when only using the native apps (e.g. the ubuntu terminal app).
Obviously xenial is a much more stable base but still, it would be good to understand what is making the difference there.
I also note that the yunit PPA seems to be missing lots of the Unity8 native apps (e.g. the browser). Is that intentional, an oversight, or something on the to-do list?
-
@webdrake nice to hear from you again. I'm sure UBports can use your skills, however, I'm not directly involved in the development work so I can't advise much. @mariogrip is the lead.
I'd only be speculating about why things seem less stable, but 18.04LTS is pre-release and Canonical have dropped a lot of the client-side support for Mir (and other Unity8 related packages). That will have an effect. Also, I'm not sure whether the UBports packages are built from a release branch, master or...
-
@alan_g I'll reach out to @mariogrip directly w.r.t. all things UBPorts.
You've been more than generous with your time, but is it OK to still ping you about Mir(AL)-related issues w.r.t. the USC refactoring? No worries if not.
On a slightly bigger note:
I would really, really urge everyone involved in UBPorts to take on the key advice here:
everyone (not just devs, or an "in crowd") must be able to see the the workflow (and status of work items).
Right now if I go to ubports.com and click on "Community" or "Join us", I get a lot of pages about stuff like the different steering committees and whatever, but (despite clicking on multiple different links), there's NOTHING about easy ways to start taking useful action.
If anything it's even more offputting because pretty much the first thing one sees on the "Get Involved" page is the link to become a member ... which jumps straight into statutes, 6-month commitment, etc. etc. etc. Most people would like to have a way to dip their toes in the water first before thinking about jumping in that deep!
It would be far better to have an easy way for people to just start doing small things, get engaged through doing stuff, and learn by experience whose commitment is up to the standard expected of full members.
-
@webdrake said in Organizing Unity8 work:
@alan_g I'll reach out to @mariogrip directly w.r.t. all things UBPorts.
You've been more than generous with your time, but is it OK to still ping you about Mir(AL)-related issues w.r.t. the USC refactoring? No worries if not.
Yes, I'm still happy to receive pings about Mir(AL) related stuff (USC or otherwise).
