Great Christian!
I'd also suggest:
* Remove that EXAMPLE project
* Make use of the Constrained Framework project (should't be renamed to
IoTivity-constrained ?)
-> Lot's of things happening on gerrit but nothing on Jira
* Move Node.js bindings component to a new IoTivity-Node project
-> Btw, Isn't it an official iotivity project?.. Can't find it on
https://wiki.iotivity.org/projects_and_functions
+1 for scrum board
On Wed, Mar 22, 2017 at 10:26 AM, Mats Wichmann <mats at wichmann.us> wrote:
> On 03/22/2017 04:04 AM, Christian Gran wrote:
> > Hi,
> >
> > as "Planning Function Lead? for IoTivity started to look a bit in how we
> use Jira :-)
> >
> > In my opinion we could do a few changes here and there and we would also
> benefit if we would update to the latest version.
> > This would make the overall planning process for IoTivity a much easier
> :-)
> >
> > I have created two Wiki pages - one for proposed changes to Jira and one
> with proposals how we could use Jira.
> > https://wiki.iotivity.org/jira_proposed_changes
> > https://wiki.iotivity.org/jira_how_to_use
> >
> > My proposal is also to use the Scrum Board, which seems to be included
> in the latest version:
> > https://www.atlassian.com/software/jira/agile#scrum
> > With the Scrum board we could much better prioritize tickets and group
> these into Sprints to plan for a release.
> >
> > Any thoughts on this?
>
> A couple of things on our Jira,
>
> I understand the need to gather complete information to diagnose a
> problem (I have been a developer responding to bug tickets for many many
> years), but it just feels like there are too many fields where an active
> choice is required - it makes reporting cumbersome. e.g. if while
> looking in the source code I find a problem which needs reporting, it's
> a pain if I have to pick between 32/64 bit; and from this viewpoint
> operating system has different granularity than from a binary viewpoint
> - code could be windows-specific, or not-target-specific, if the former
> I don't want to figure out which of the windows variants is applicable).
> Could you take a careful look at whether some fields could either become
> non-mandatory, or else start with a sane default and you only change it
> if needed.
>
> In the same light, improving the categories would be really helpful -
> the proposal generally looks good. I wouldn't drop Remote Access...
> there will be more remote access activity in future, and maybe cloud
> belongs in that bucket?
>
> A build category would be good; if "install/uninstall" has been used
> this way, why not rename it to build? (I think there will be a build
> maintainer presently)
>
> What should be the policy (hate to use that word :) on linking with
> gerrit? Do proposed patches get linked in Jira? Or is the linkage the
> other direction, the Jira link goes in gerrit? Or both? And if in the
> Jira ticket, where do the links go? In a field, or in comments?
>
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>
--
*Thiago Guedes Cunha de Moura*
Graduando em Ci?ncia da Computa??o
Instituto de Ci?ncias Exatas e Biol?gicas - Universidade Federal de Ouro
Preto
cel.: (31)99484-9864
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170323/0e6d1e09/attachment.html>
