Tech Review Process (v1)

[Daniel Nauschuetz]

Here is a copy of the process that we've talked about so far.  Essentially, a user submits an idea or request to a Message Board.  The Board Member or Policy Coordinator may decide to take action.  If they do, they follow their respective guidelines.  We do not really have an organizational approach to letting users know when we are not going to take action, but many Board Members and Policy Coordinators will likely send an email to ensure we don't have disenchanted members.

There is a third "branch" that I tabled earlier.  What is our initial process for items that are NOT date entry or mission scope?

The first question I recall hearing is "what are we talking about here?"  That is a fair question since it isn't something that I've seen really addressed at a higher level.  There are a few things that come to mind, but I am specifically talking about our web page.  It is nearly as important to data entry to me because it is our interface with the outside world.  I can think of plenty examples but will resist the temptation since I don't want to go down rabbit holes.  

I suspect our answer will be to have a user submit a Tech Ticket with their request (since it was mentioned earlier).  If there is no contradiction to this approach (and need to have a clear path in the first place), then I will update the diagram.  

Does a user have to have a separate account to submit a Tech Ticket?

Thank you again,

Daniel 

[Tony Rose]

The flowchart in accurate.

I think you're right, that changes to the display would be addressed by a bug ticket.

A user must have a bug account to submit a bug ticket.  It is a different account from an indexer account.  I'm pretty sure I have an account, but I can't remember my user name or my password.  I suppose I need to get those in light of the upcoming redesign.




tony

---

From: "Daniel Nauschuetz" <nausc...@yahoo.com>
To: gcd-...@googlegroups.com
Sent: Sunday, March 10, 2013 7:54:27 PM
Subject: [gcd-board] Tech Review Process (v1)

--
--
GCD-Board mailing list - gcd-...@googlegroups.com
To unsubscribe send email to gcd-board+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/gcd-board
 
---
You received this message because you are subscribed to the Google Groups "gcd-board" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gcd-board+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Daniel Nauschuetz]

Good news Tony, thank you.  I am waiting for a few more responses before get to the root of the problem I see with this branch.

In the meantime, would it be fair to say that a second possible management risk is that we require users to have a SECOND account in order to simply submit tech tickets to request changes?

Daniel

---

From: Tony Rose <tonyr...@comcast.net>
To: gcd-...@googlegroups.com
Sent: Monday, March 11, 2013 12:05 PM
Subject: Re: [gcd-board] Tech Review Process (v1)

[Merlin Haas]

>Good news Tony, thank you. I am waiting for a few more responses
>before get to the root of the problem I see with this branch.
>
>In the meantime, would it be fair to say that a second possible
>management risk is that we require users to have a SECOND account in
>order to simply submit tech tickets to request changes?
>
>Daniel

I see your point. I don't have a bug account and have never even
looked at that tech list. (I suppose I need to, if there's going to
be a redesign, though it's not something I have a lot of expertise
in.)
We actually have three accounts: the bug account for tech; the
error list for those who aren't indexers, and the regular indexing
account. And all require user names and passwords.

-- Merlin Haas

>
>
>From: Tony Rose <tonyr...@comcast.net>
>To: gcd-...@googlegroups.com
>Sent: Monday, March 11, 2013 12:05 PM
>Subject: Re: [gcd-board] Tech Review Process (v1)
>
>

>#yiv1848090133 p {margin:0;}

>The flowchart in accurate.
>
>I think you're right, that changes to the display would be addressed
>by a bug ticket.
>
>A user must have a bug account to submit a bug ticket. It is a
>different account from an indexer account. I'm pretty sure I have
>an account, but I can't remember my user name or my password. I
>suppose I need to get those in light of the upcoming redesign.
>
>
>
>
>tony
>
>

[Daniel Nauschuetz]

Good call!  I kinda tabled the Error Tracking tool for a bit, but you are right, there is a third account that we would need to have users sign up for in order to fully participate in this part of the GCD.

Daniel

---

From: Merlin Haas <mvh...@elpaso.net>
To: gcd-...@googlegroups.com
Sent: Monday, March 11, 2013 9:59 PM

-- -- GCD-Board mailing list - gcd-...@googlegroups.com

To unsubscribe send email to gcd-board+unsub...@googlegroups.com

For more options, visit this group at http://groups.google.com/group/gcd-board

--- You received this message because you are subscribed to the Google Groups "gcd-board" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gcd-board+unsub...@googlegroups.com.

[Donald Dale Milne]

    I'm having a hard time seeing what problem we are addressing here, sorry.  No one needs to sign up for any of these accounts to propose changes.  One need only propose something on any one of the mailing lists: tech, chat, main, or policy, which anyone (not just members) can join.  Not only can one propose something, he can also offer arguments or even run a discussion all the way to a policy vote, or try to get a Board member to champion his cause here.

    The diagram Daniel offered is correct as I see it.  The "No" area is a black hole, granted, but no more so than many organizations.  For example, if you proposed something to your local city councilman and he does nothing with the idea, you typically do not hear back from him.  I would like us to be better than that, and offer some feedback e-mail, but I really don't see a need for anything more.

- Don Milne

To unsubscribe send email to gcd-board+...@googlegroups.com

For more options, visit this group at http://groups.google.com/group/gcd-board
 
---
You received this message because you are subscribed to the Google Groups "gcd-board" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gcd-board+...@googlegroups.com.

[Tony Rose]

I'm not sure that it is a management risk.  But, that phrase may have special management-speak meaning of which I'm unaware.  My thinking is that if it was really easy to submit a tech ticket -- if it used your indexer account username and password -- then we'd get *lots* of tickets that we might not be very well considered at all.  As it stands now, a person has to make a special effort -- get a different account -- to file the ticket.




tr

---

From: "Daniel Nauschuetz" <nausc...@yahoo.com>
To: gcd-...@googlegroups.com

Sent: Monday, March 11, 2013 8:18:41 PM

[Tony Rose]

So far, there are no proposals for anything more.  The "black hole" needs to be addressed and I think when we've seen Daniel through on this review, we'll be better able to address what we need to do about that "hole."




tony

---

From: "Donald Dale Milne" <dond...@att.net>
To: gcd-...@googlegroups.com
Sent: Monday, March 11, 2013 10:13:22 PM

[Lionel English]

The "requirement" that users have separate accounts to index, use the wiki, perform code review, and submit bugs to the error tracker or bugzilla is not by design. It's because the first (indexing) relies on home-grown code (the heart of the project) while the others use pre-existing packages that have been minimally customized for our use.

There is, in fact, a bug out there to implement single site-wide user log in. Andres and Alexandros might be able to speak to that a bit more. I believe Alexandros took a stab at it a couple of years ago and had some problems getting it to work, but the project has not been abandoned. 

Most of those problems--and a lot of others--are attributable to our sudden forced migration to new servers and the need to set up both the web site and infrastructure quickly. The old site had the database and some limited documentation and not much else. Error tracking was done via a mailing list. There was no wiki. There was no code review, nor anyplace to submit bugs or feature requests. If you wanted something done you could ask Jon, but it was far less likely it would get done than it is today. Jon owned the machine and controlled access to the machine and he did what he wanted to do with no real accountability to the board.

The current site is not adequately staffed from a tech perspective, but it was set up with the goal, at least, of making things more open and more responsive--there now is a place where people can submit bug and feature requests, there's a wiki for volunteers to maintain documentation, code is designed to be peer reviewed and beta tested, etc.

Lionel English

San Diego, CA
lio...@beanmar.net

shoebutton on Google Talk

[Daniel Nauschuetz]

I agree.  Risk Management is perhaps not really how this may be described.  I will find a better term.

You actually started on one of the directions I was heading.  Let's assume that it is easier to submit tickets and we do get lots of tickets.  Who actually makes the decision of what is well considered or not?

The Board has a voting process to determine what will pass and what we agree to.  The Policy List has a larger body of voters to determine what will be permitted and what will not be permitted.  What is the voting process (or selection process) for our web changes?

I want to be careful here.  This is not a question about technically feasible.  That conversation is squarely in the Tech Team's arena which I am committed to staying out of.  This is a question about what we want and don't want as an organization.  Where do I get a voice as to how our web page looks? Where do I get a vote on whether widget X gets implemented or not?  As Tony implied, somebody has to make a call if it is well considered or not (much like we do for Board and Policy items).  

One more caveat.  This is focused on change requests and web page behavior/appearance.  Actual problem reports, by necessity, get done as occurring by the Tech Team with little external involvement.  

Daniel

---

From: Tony Rose <tonyr...@comcast.net>
To: gcd-...@googlegroups.com

Sent: Tuesday, March 12, 2013 9:48 AM

[Daniel Nauschuetz]

I am going to take the silence as "move along, nothing to see here."  I attached an updated diagram to reflect our current position on this.  We have three paths: Program Scope, Data, Web Sites.  In two of them, we have an approval process that essentially "authorizes" a Tech Ticket.  In the third, anybody can add a Tech Ticket.  I have a question mark along the third path because there are some issues with this approach that we can't really address until we get further down the line in the process (issues like volunteer resource allocation and product approval).  

In the meantime, you've collectively answered the questions I posed on Tuesday.

Let me know if this drawing is accurate, and I will move along to the next topic.

Daniel

---

From: Daniel Nauschuetz <nausc...@yahoo.com>

To: "gcd-...@googlegroups.com" <gcd-...@googlegroups.com>
Sent: Tuesday, March 12, 2013 10:23 PM

[Tony Rose]

There is, of course, the "unnapproved" path for both project and data.

Otherwise, it reflects what we've discussed the last few days.

tr

---

From: "Daniel Nauschuetz" <nausc...@yahoo.com>
To: gcd-...@googlegroups.com

Sent: Saturday, March 16, 2013 2:09:39 PM
Subject: [gcd-board] Tech Review Process (v2)

[Daniel Nauschuetz]

LOL....yes, there is that.  We can't account for what clever people will do but attempt to control it at a management level.

Thank you for the feedback,

Daniel

---

From: Tony Rose <tonyr...@comcast.net>
To: gcd-...@googlegroups.com

Sent: Sunday, March 17, 2013 2:22 PM
Subject: Re: [gcd-board] Tech Review Process (v2)

[Daniel Nauschuetz]

Excellent back and forth over the last week, but I think that we should move on.

At this point, the Board or the Policy List or any user will submit a Tech Ticket for their respective lanes.  How do they identify the priority of the work?  All work gets put into a Tech queue from which any developer can select work to do, so this isn't a question of HOW work will be done.  It is a question of how do we express intent and desire to get approved work done.

What is our priority schema?

Let me stress (because this has been a point of contention in the past), we are not talking about internal technical work assignment or dictating any task.  This is a question of identifying our method of conveying what each voting body expects regarding the relative importance of the Tech Ticket submitted.

Daniel

---

From: Daniel Nauschuetz <nausc...@yahoo.com>
To: "gcd-...@googlegroups.com" <gcd-...@googlegroups.com>

Sent: Sunday, March 17, 2013 2:36 PM

[Merlin Haas]

The Error list has a Priority setting for each error (not that anyone
pays much attention to it.) Does the Tech Ticket have something
equivalent? If not, should it?

We're pretty much stuck with whatever Tech wants to work on, but if
we ever get more tech people it might be helpful for them to know
what we'd like to have added/corrected first.

best -- Merlin Haas

>Excellent back and forth over the last week, but I think that we
>should move on.
>
>At this point, the Board or the Policy List or any user will submit
>a Tech Ticket for their respective lanes. How do they identify the
>priority of the work? All work gets put into a Tech queue from
>which any developer can select work to do, so this isn't a question
>of HOW work will be done. It is a question of how do we express
>intent and desire to get approved work done.
>
>What is our priority schema?
>
>Let me stress (because this has been a point of contention in the
>past), we are not talking about internal technical work assignment
>or dictating any task. This is a question of identifying our method
>of conveying what each voting body expects regarding the relative
>importance of the Tech Ticket submitted.
>
>Daniel
>
>
>

>From: Daniel Nauschuetz <nausc...@yahoo.com>
>To: "gcd-...@googlegroups.com" <gcd-...@googlegroups.com>
>Sent: Sunday, March 17, 2013 2:36 PM
>Subject: Re: [gcd-board] Tech Review Process (v2)
>
>
>LOL....yes, there is that. We can't account for what clever people
>will do but attempt to control it at a management level.
>
>Thank you for the feedback,
>Daniel
>
>

>From: Tony Rose <tonyr...@comcast.net>
>To: gcd-...@googlegroups.com
>Sent: Sunday, March 17, 2013 2:22 PM
>Subject: Re: [gcd-board] Tech Review Process (v2)
>
>

>#yiv675791113 p {margin:0;}

>There is, of course, the "unnapproved" path for both project and data.
>
>Otherwise, it reflects what we've discussed the last few days.
>
>
>
>tr
>
>

>From: "Daniel Nauschuetz" <nausc...@yahoo.com>
>To: gcd-...@googlegroups.com
>Sent: Saturday, March 16, 2013 2:09:39 PM
>Subject: [gcd-board] Tech Review Process (v2)
>
>I am going to take the silence as "move along, nothing to see here."
> I attached an updated diagram to reflect our current position on
>this. We have three paths: Program Scope, Data, Web Sites. In two
>of them, we have an approval process that essentially "authorizes" a
>Tech Ticket. In the third, anybody can add a Tech Ticket. I have a
>question mark along the third path because there are some issues
>with this approach that we can't really address until we get further
>down the line in the process (issues like volunteer resource
>allocation and product approval).
>
>In the meantime, you've collectively answered the questions I posed
>on Tuesday.
>
>Let me know if this drawing is accurate, and I will move along to
>the next topic.
>
>Daniel
>
>

>From: Tony Rose <tonyr...@comcast.net>
>To: gcd-...@googlegroups.com
>Sent: Tuesday, March 12, 2013 9:48 AM
>Subject: Re: [gcd-board] Tech Review Process (v1)
>
>

>#yiv675791113 p {margin:0;}

>I'm not sure that it is a management risk. But, that phrase may
>have special management-speak meaning of which I'm unaware. My
>thinking is that if it was really easy to submit a tech ticket -- if
>it used your indexer account username and password -- then we'd get
>*lots* of tickets that we might not be very well considered at all.
>As it stands now, a person has to make a special effort -- get a
>different account -- to file the ticket.
>
>
>
>
>tr
>
>

>From: "Daniel Nauschuetz" <nausc...@yahoo.com>
>To: gcd-...@googlegroups.com
>Sent: Monday, March 11, 2013 8:18:41 PM
>Subject: Re: [gcd-board] Tech Review Process (v1)
>
>Good news Tony, thank you. I am waiting for a few more responses
>before get to the root of the problem I see with this branch.
>
>In the meantime, would it be fair to say that a second possible
>management risk is that we require users to have a SECOND account in
>order to simply submit tech tickets to request changes?
>
>Daniel
>
>

>From: Tony Rose <tonyr...@comcast.net>
>To: gcd-...@googlegroups.com
>Sent: Monday, March 11, 2013 12:05 PM
>Subject: Re: [gcd-board] Tech Review Process (v1)
>
>

>#yiv675791113 p {margin:0;}

>The flowchart in accurate.
>
>I think you're right, that changes to the display would be addressed
>by a bug ticket.
>
>A user must have a bug account to submit a bug ticket. It is a
>different account from an indexer account. I'm pretty sure I have
>an account, but I can't remember my user name or my password. I
>suppose I need to get those in light of the upcoming redesign.
>
>
>
>
>tony
>
>

><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.

>
>
>
>--
>--
>GCD-Board mailing list - gcd-...@googlegroups.com
>To unsubscribe send email to gcd-board+...@googlegroups.com
>For more options, visit this group at

><http://groups.google.com/group/gcd-board>http://groups.google.com/group/gcd-board

>
>---
>You received this message because you are subscribed to the Google
>Groups "gcd-board" group.
>To unsubscribe from this group and stop receiving emails from it,
>send an email to gcd-board+...@googlegroups.com.
>For more options, visit

><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.

>
>
>
>
>
>--
>--
>GCD-Board mailing list - gcd-...@googlegroups.com
>To unsubscribe send email to gcd-board+...@googlegroups.com
>For more options, visit this group at

><http://groups.google.com/group/gcd-board>http://groups.google.com/group/gcd-board

>
>---
>You received this message because you are subscribed to the Google
>Groups "gcd-board" group.
>To unsubscribe from this group and stop receiving emails from it,
>send an email to gcd-board+...@googlegroups.com.
>For more options, visit

><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.

>
>
>
>--
>--
>GCD-Board mailing list - gcd-...@googlegroups.com
>To unsubscribe send email to gcd-board+...@googlegroups.com
>For more options, visit this group at

><http://groups.google.com/group/gcd-board>http://groups.google.com/group/gcd-board

>
>---
>You received this message because you are subscribed to the Google
>Groups "gcd-board" group.
>To unsubscribe from this group and stop receiving emails from it,
>send an email to gcd-board+...@googlegroups.com.
>For more options, visit

><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.

>
>
>
>
>
>--
>--
>GCD-Board mailing list - gcd-...@googlegroups.com
>To unsubscribe send email to gcd-board+...@googlegroups.com
>For more options, visit this group at

><http://groups.google.com/group/gcd-board>http://groups.google.com/group/gcd-board

>
>---
>You received this message because you are subscribed to the Google
>Groups "gcd-board" group.
>To unsubscribe from this group and stop receiving emails from it,
>send an email to gcd-board+...@googlegroups.com.
>For more options, visit

><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.

>
>
>
>
>
>--
>--
>GCD-Board mailing list - gcd-...@googlegroups.com
>To unsubscribe send email to gcd-board+...@googlegroups.com
>For more options, visit this group at

><http://groups.google.com/group/gcd-board>http://groups.google.com/group/gcd-board

>
>---
>You received this message because you are subscribed to the Google
>Groups "gcd-board" group.
>To unsubscribe from this group and stop receiving emails from it,
>send an email to gcd-board+...@googlegroups.com.
>For more options, visit

><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.

>
>
>
>--
>--
>GCD-Board mailing list - gcd-...@googlegroups.com
>To unsubscribe send email to gcd-board+...@googlegroups.com
>For more options, visit this group at

><http://groups.google.com/group/gcd-board>http://groups.google.com/group/gcd-board

>
>---
>You received this message because you are subscribed to the Google
>Groups "gcd-board" group.
>To unsubscribe from this group and stop receiving emails from it,
>send an email to gcd-board+...@googlegroups.com.
>For more options, visit

><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.

>
>
>
>
>
>--
>--
>GCD-Board mailing list - gcd-...@googlegroups.com
>To unsubscribe send email to gcd-board+...@googlegroups.com
>For more options, visit this group at

><http://groups.google.com/group/gcd-board>http://groups.google.com/group/gcd-board

>
>---
>You received this message because you are subscribed to the Google
>Groups "gcd-board" group.
>To unsubscribe from this group and stop receiving emails from it,
>send an email to gcd-board+...@googlegroups.com.
>For more options, visit

><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.

>
>
>
>
>
>--
>--
>GCD-Board mailing list - gcd-...@googlegroups.com
>To unsubscribe send email to gcd-board+...@googlegroups.com
>For more options, visit this group at

><http://groups.google.com/group/gcd-board>http://groups.google.com/group/gcd-board

>
>---
>You received this message because you are subscribed to the Google
>Groups "gcd-board" group.
>To unsubscribe from this group and stop receiving emails from it,
>send an email to gcd-board+...@googlegroups.com.
>For more options, visit

><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.
>
>

[Lionel English]

The person submitting the bug may assign a priority to it (there's a default mid-level priority). A developer may change the priority.

[Daniel Nauschuetz]

Is that priority posted?  and more importantly, is that priority customized for the GCD?

Again, I am not referring to work level priority but organizational priority.  Is the Genre drop-down menu important to us?  What about MyComics?  What is our (Board, Policy, membership) priority on any given topic?  Typically, these items can NOT be changed by the Tech Team since they reflect the priority of the requirement and not the implementation. 

In fact, it wouldn't be uncommon for management to re-evaluate (on a periodic bases) the individual priority of big ticket desires.  We as an organization really want this first, this second, and this third.  Whether the Tech Team does the work in that order is not what I am focusing on here.  Rather, a resource becomes available to do any work and asks "what can I do?".  This list, in effect, becomes an organizational guide.

This does not imply that the Tech Team is out of the loop.  Quite the opposite.  The Tech Lead is responsible for providing Technical Feasibility of each item giving the management guidance on creating a more realistic set of goals when establishing organizational priorities.  We have the pieces.

This all stems from an initial priority set by the user that is clearly defined and accessible.

Daniel

---

From: Lionel English <lio...@beanmar.net>
To: GCD Board <gcd-...@googlegroups.com>
Sent: Saturday, March 23, 2013 11:28 PM

[Daniel Nauschuetz]

Lionel,

The documentation is inadequate.  The "Severity" that applies to all this is simply "Enhancement" since all the remaining severity codes deal with bugs (which is outside our scope here).  The Priority is even less helpful:  "This field describes the importance and order in which a bug should be fixed. This field is utilized by the programmers/engineers to prioritize their work to be done. The available priorities range from P1 (most important) to P5 (least important)." Again, this implies resource allocation and not organizational requirements.

Daniel

---

From: Daniel Nauschuetz <nausc...@yahoo.com>
To: "gcd-...@googlegroups.com" <gcd-...@googlegroups.com>

Sent: Sunday, March 24, 2013 12:03 AM
Subject: Re: [gcd-board] Tech Review Process (v2)

[Donald Dale Milne]

    In terms of "...this first, this second, and this third." and as "...a resource becomes available to do any work and asks "what can I do?", I don't believe we currently have any priorities set for much of anything.  I see this as applying to more than just tech issues.  We really don't have priorities set for revenue enhancement, PR and advertising, cooperation projects with other sources, outreach to creators, documentation clean-up, social engagement, data enhancement, or anything else.  Are you looking at us prioritizing our entire range of activities?  While I agree that it needs to be done, we are also volunteers and that may not be our priority (no joke intended).

- Don Milne

[Daniel Nauschuetz]

You are right, of course.  I am getting way ahead of myself.  I want to focus on how a user (Board, Policy Coordinator, etc) determines priority for submitting a Tech Ticket as it relates to user expectation.

On a related note, identifying all things we want done is an independent exercise as to how it will get done.  We can NOT let resource restrictions limit our understanding of what does and doesn't need to be done. 

Daniel

---

From: Donald Dale Milne <dond...@att.net>

To: gcd-...@googlegroups.com
Sent: Sunday, March 24, 2013 11:02 AM
Subject: Re: [gcd-board] Tech Review Process (v2)

[Tony Rose]

I am not ignoring this thread.  I'm cogitating.

tr

---

From: "Daniel Nauschuetz" <nausc...@yahoo.com>
To: gcd-...@googlegroups.com

Sent: Saturday, March 23, 2013 6:19:52 PM