Cap 19, 00 / Dec 20, 16 23:51 UTC

CT/IT - Question about the Software processes (Project Management, Development Processes,Ticket Systems, ...)  

Hey,
is it to early to bring the below questions up?
I wanted to ask that already in the Facebook Group (https://www.facebook.com/groups/asgardiait/) but as we now have a forum for that it makes it more convenient to ask directly here.
Shortly to me, I worked so far just in 2 Software Companies for 2 years (1000+ employees: Browser+Mobile Games and <30 employees Mobile App; both "start ups"). I mostly have a QA backround with low amount of programming but much organizational and process defining next to the QA part. I have seen some flaws in not deciding what should be how used and the unecessary delay in things and hurdles afterwards. So I wanted to bring some of them atleast to the surface. :)

Questions:

  1. Can we assure somehow that software development processes of different projects for Asgardia are very similar to each other, so people can easily switch around if wanted or needed? Not only from a Dev/PM/QA/... Position perspective also for information finding and getting rid of delays in the asking process.
  2. As I undstood so far, we need to have a basic Team Structure for Software Projects of all kind. The Structure has to be dynamic in some ways, so that smaller Projects don't need all "Postions" filled when starting or a Person can "do them all". I think we have to discuss about that?
  3. Is it necessary for an Asgardian Software Project to have a Ticket System and advanced Documentation (like additional Wikis)? I say yes as QA and seen to a future point when Asgardian Software may have to be refactored by other persons/teams and basic understanding so it can maybe futher developed from the point on when development maybe was paused or stopped.
  4. Should Asgardian Software always be open source and/or free?
  5. What are the basics to start any Asgardian Software Project? As I saw Asgardian IT Facebook Admin Alex Fiume writting that a proposal is needed to start anything official related to Asgardia, we maybe should bring up a Process, atleast written down?
  6. For software which is given out for use for the Asgardian Citizens are we using their feedback always to make the software better and more usefull or do we act like a "Opinion-maker" as the Earth-Industry commonly does in our current era? (eg. Social Platform)
  7. Will we have some sort of Hirachie, overall not only in the IT? (not sure though if that question got somewhere answeared already in the hundereds of facebook groups)
  8. If we follow standardazation, how do we do it?
  9. As we are applying software development methodolgy in some way, should we standardize it and so which one to use?
  Last edited by:  FlorianH (Asgardian)  on Aqu 02, 01 / Jan 2, 17 19:15 UTC, edited 1 time in total.
Reason: Added Question 8 and 9 (standardazation and software dev methodology)

Cap 19, 00 / Dec 20, 16 23:59 UTC

I've subscribed because the questions are important. I think in the coming weeks some will be answered; the forum is a much more suited place for dissemination of info.

Cap 20, 00 / Dec 21, 16 08:34 UTC

In regards to the software/ticketing systems; I'd love to help with that if I can. I've worked with two different IT/Help desk ticketing systems, and built our own using Spiceworks ticketing software. We've been live for the past two years, and the software comes with an inventory system to help with hardware and end-user support.

Cap 20, 00 / Dec 21, 16 20:41 UTC

hola me suscribí por que en realidad me gusta y me interesa mucho el tema de la tecnología es una parte de asgardia importante como todas claro pero en especial esta me gusta actualizarme en todo lo nuevo en tecnología y a mi me gustaría ser parte de esto y quiero aprender mas de mis metas y mis limites que tengo en conocimiento.

Hi I subscribed because I really like and I am very interested in the subject of technology is a part of asgardia important as all clear but especially this I like to update in everything new in technology and I would like to be part of this and I want Learn more of my goals and my limits that I have in knowledge.

Admin Edit: The above translation is provided by Google Translate. Please remember to use English when communicating. Any translation done with an online translator is perfectly acceptable.

  Last edited by:  Alex Fiume (Asgardian)  on Cap 20, 00 / Dec 21, 16 20:48 UTC, edited 1 time in total.

Cap 20, 00 / Dec 21, 16 21:51 UTC

I am also interesting on this questions!! I think that they are very important to us.

Cap 21, 00 / Dec 22, 16 17:50 UTC

Maybe we can come up with a Mantis tracker or something like that.

I am waiting it as well :)

Cap 26, 00 / Dec 27, 16 02:03 UTC

As well as ticketing systems, other systems could be useful. Like racktables - a wonderful asset management system designed for datacenters, but repurposeable to serve quite a few uses.

Answers:

  1. Yes. Software development can assume the same loose structure as any other type of project. Once there's definition of policies and procedures, this should be easier to assure.
  2. With crowdsourcing to complete projects - which given our number and their diverse strengths would be fatally stupid to avoid - formal structure isn't entirely required, but for sake of co-ordination, as various ministries define projects for completion, they can also define a "Team leader" to keep all working on said project in a productive fashion, and to source extra/knowledge skills for various facets as required from relevant ministries.
  3. A ticketing system is likely to be required - what sort of person would consider deploying multi-facet public-facing services without? possibly the sort of person that would use faceboook... An additional wiki isn't a poor idea, I put up a feature request for such the other day. It can be used to host most "static content".
  4. Without quesiton it should. If Asgardian software wasn't open source, how could we possibly even pretend to adhere to the core principles of furthering knowledge and understanding?
  5. An official process should(will) be ratified in order to define which ministries deal with what proposals, and how. But basically all that's required to start should be a proposal, and if warrented merit how to proceed from there would define itself in the relevant discussions that cover the potential failure points and other concerns leading up to the descision to proceed.
  6. There's some facets of Asgardian-provided services that could technically be described as a "social platform" - but unless you're harbouring intent to be mimicking ethically questionable conduct of companies like facebook with regard to manipulation of social perception, it might be wise to avoid terms like "opinion-maker". Feedback should always be used to make things better - not just software - with regards to "more useful" it's critical to ensure the additions truely provide extra functionality and does just add "feature creep".
  7. There's already some form of hierachy established. Currently ministries for various topics - once these begin to organise themselves they will establish relevant heirachies within themselves.
  Updated  on Cap 26, 00 / Dec 27, 16 02:05 UTC, edited 1 time in total.
Reason: typo

Cap 27, 00 / Dec 28, 16 02:04 UTC

Hey, is it to early to bring the below questions up? I wanted to ask that already in the Facebook Group (https://www.facebook.com/groups/asgardiait/) but as we now have a forum for that it makes it more convenient to ask directly here. Shortly to me, I worked so far just in 2 Software Companies for 2 years (1000+ employees: Browser+Mobile Games and <30 employees Mobile App; both "start ups"). I mostly have a QA backround with low amount of programming but much organizational and process defining next to the QA part. I have seen some flaws in not deciding what should be how used and the unecessary delay in things and hurdles afterwards. So I wanted to bring some of them atleast to the surface. :)

Questions:

Can we assure somehow that software development processes of different projects for Asgardia are very similar to each other, so people can easily switch around if wanted or needed? Not only from a Dev/PM/QA/... Position perspective also for information finding and getting rid of delays in the asking process.
As I undstood so far, we need to have a basic Team Structure for Software Projects of all kind. The Structure has to be dynamic in some ways, so that smaller Projects don't need all "Postions" filled when starting or a Person can "do them all". I think we have to discuss about that?
Is it necessary for an Asgardian Software Project to have a Ticket System and advanced Documentation (like additional Wikis)? I say yes as QA and seen to a future point when Asgardian Software may have to be refactored by other persons/teams and basic understanding so it can maybe futher developed from the point on when development maybe was paused or stopped.
Should Asgardian Software always be open source and/or free?
What are the basics to start any Asgardian Software Project? As I saw Asgardian IT Facebook Admin Alex Fiume writting that a proposal is needed to start anything official related to Asgardia, we maybe should bring up a Process, atleast written down?
For software which is given out for use for the Asgardian Citizens are we using their feedback always to make the software better and more usefull or do we act like a "Opinion-maker" as the Earth-Industry commonly does in our current era? (eg. Social Platform)
Will we have some sort of Hirachie, overall not only in the IT? (not sure though if that question got somewhere answeared already in the hundereds of facebook groups)

it a good idea

Cap 27, 00 / Dec 28, 16 19:24 UTC

@FlorianH and those others above...I believe we should start setting some ground rules for implementing any projects that will be focused towards our core Asgardian nation. The International Space Station has a 'god' book, if you will. All countries that are involved adding modules and equipment are required to use a default set of measurements and coding. While a lot of technology is being tested, when the first two modules were being connected in space, they were not getting a solid 'lock' on the docking collar. When the approval was given to release the arm that was connected to the shuttle to the module, the tension had been the problem. Docking collar was perfect due to the diligence of the scientists that worked together using the same systems. As we go forward, programming languages, server systems, etc, should start being set up to use a standard. If Asgardians wish to create a project, they should be using the standards. I won't disavow that there are pros and cons to different systems, however, it will be harder to implement these things as we go forward. If you want to help, learn how and where to help the core. Let's expand from there, and build up...but we need a solid foundation to begin with.

Aqu 02, 01 / Jan 2, 17 15:31 UTC

+1 standards. Ofc such an argument instantly leads to me thinking: https://imgs.xkcd.com/comics/standards.png

Not just code(realistically, the code itself doesn't really matter that much, as long as there's some sort of transport, like an API, and it matters even less on a hardware base as long as it can be lent common physical port interface), or connecting systems like docking ports(about the only standardised system on ISS, and there's even a few types of that: PMA, CBM, APAS/APDS, IDA, NDS), but even down to screws... The more things that are "standardised" the easier it will be(if sane sandards are selected) to repurpose or expand existing things in a modular fashion in the future.

Aqu 02, 01 / Jan 2, 17 19:13 UTC

Thanks for contributing in this discussion everyone.

Yes to standardizing as you already said, it makes modularity possible and even worth the reusing of things already done or partly done by others in the past or even parallel.
I will add that to the original post as question, how we should standardize.
Also adding the question about if and which software development methodology as a framework should be used if we start standardazing.

But would we go even into the ISO formats with the standardizing? Referring to ISO 9001 in an ongoing development cycle. I think if ISOs applied to all projects, solo adventures and small teams can't apply them as things get hardend to much to get things done. It's like you have this plan right there, but you don't do X parts of it, so you need no more plan as you litterally tweaked around it. "Cut the seemingly unneeded until you think it's neccessary." (Doesn't really follow a standardasation, does it?)
Still about ISO, of course 1 could place all the positions but it doesn't really make sense as they have to be independent as much as possible to get it more fluent in most ways possible, I think more independency of a stakeholder secures more quality.
If we do standardazation then, has everyone need to follow them for every even so small project? I say no depending on the size of the expected effort for the proposed project.

I would like to see something like the CMM - Capability Maturity Model developed by SEI. http://www.softwaretestinghelp.com/what-is-sei-cmm-iso-ieee-ansi-will-it-help/ A Level 1 and maybe Level 2 should be tried to avoid anywhere in any software project which corresponds to asgarida. From my point of view these 2 Levels are not modular in anyway and most small unexperienced teams do them atleast in the beginning.
A Level 5 would be the goal then according to the CMM.

Also the basics if not further "everything" (eg. "Agile is Life") in software development methodologies could be standardized.

  1. How long is a Sprint.
  2. Sprint Meetings happen, if the team is big enough.
  3. Features get planned and written down.
  4. And so on.

Software development methodologies are (just some): Agile, Lean, Scrum, Waterfall, ...

  Last edited by:  FlorianH (Asgardian)  on Aqu 02, 01 / Jan 2, 17 19:17 UTC, edited 1 time in total.

Aqu 03, 01 / Jan 3, 17 15:13 UTC

I am another vote for a Spice-works type system. it's easy to use and very effective.

Aqu 05, 01 / Jan 5, 17 23:16 UTC

When I was talking standards, I wasn't just talking of softawre development - Everything. "ISO Formats" are possibly a good idea. They are already established standards, and would not involve re-inventing the wheel. I can't instantly think of any that conflict with another - but I'm not overly conversant on every ISO document. There are one or two.

To address 9001 in particular, I personaly think most "features" are inherent or implicit in the "problem identified, we crowd-source solution, improve solution over time" model. Previous experience of such things suggests remarkable effectiveness. With accepting any input for code, only sane code is likely to be selected, but some sort of formal standards on things like comments, formatting etc would make a more uniform experience - like other standards, it's up to the "hobbyist" if they want to adhere to them or not. Those having an interest in applicable fields tend to seek out ISO's for, RFC's etc if only to gain more information.

The state of Asgardian software development will look a lot like Level 1 depicted in your link for some time, by my prediction(based on presented evidence) however, I like to think our number features enough appropriate skill to refine any unwise submissions. But don't forget, chaos too can be a system. It seems to do a good enough job of imposing impression of order on the universe... Over time this will naturally improve. We will have educational capabilites(technically, we could pull that off just with the forum) to assist with such notions and "experts" in the appropriate areas will take up residence for additional guidance, clarification, assistance etc from there being a self-feedback loop that will grow itself past Level 5 that quickly you won't see Level 4. Which isn't much of an issue, we have little need of user-based metrics to track "productivity" - They isn't on payroll, and who cares who does what? what matters is it's done, and done well.

The four points you list would exist in part via the current model. Forum topics effectively can suggest projects, instead of "meetings" there's chaotic posting - but that's like many conversations in a single room.. The textual nature means any features planned are recorded - it's a case of picking through the jumble and assembling it into a tangible proclaimation. ID features, argue about that some. ID ways of providing these features, argue about that some more, From that mess extract all of purpose which aligns intent, maybe argue about that some more - then it's possibly beyond the four points listed and actually building it.

To use a real-world example of the open source car - a common chassis design(based on Smart/Mercedees A class), but everything else is modular. End user can snap together a car almost like lego, with equal flexibility. Several large auto firms are working collaboratively to ensure the individual parts "all fit". To do that, they are working to common standards(and working together to define new standards).

This sort of mentality is essential in software. We need to model our framework(Currently, it's looking like Drupal, That can work, tho) within which we can bolt on our modular parts. To do that, we need to be building code to common standards to ensure all the parts fit, and don't have "unintended consequences". Like the car, start with the chassis. Get the framework well mapped, then provide instructions and guidelines for use, commonly things largely take care of themselves from that point. Any parts fit the chassis and can be selected at will.

If they sensibly use our open sourced materials as base(when we actually have some), they should be somewhat complient at least up to their additions.

To address "core systems", just as an indentification excersize not to consider interactions etc, in order of priority, we need:

 *Collaborational tools - from here we can build. Everything. Typical document(text, spreadsheet, database, pictures, .pdf etc) multiuser real-time editing. Incrimental backups of content. These can further be embedded into other services. I'm sure we can spare at least 1TB of HD to holding our output(for now).
 *Ticketing systems - this will allow to track issues, across more than just software developments.
 *Secure voting system(prequisites passports, in my model at least)
 * ...

To build something that represents what you intended, it is first sensible to address what it is you would like it to do. After fully identifying our intended features(for now, it would suffice to concentrate on collab»tickets) it would be sane to review how they are intended to interact. Then how they are not intended to interact. From that guidelines can be drafted, argued, adjusted, published. Care at all stages should be made to retain modular flexibility, and promote sane handling of data. Long term stability is mission critical. Taking such into account should allow to define standards to which must be attained/maintained in order for anything submitted to proceed further, such things kind of build themselves in the same way physics shapes the universe(or, more accurately, the universe shapes physics) if approached in the right manner.

For collaborational tools, we would require a storage pool within which to host Asgardian generated documents, but more critically we need guidelines and Accepable use Policy for it's effective, and productive use. Ideally, user access would require to be seperately attributable to the forum, maybe a flag in appropriate(service, not citizen) DB to indicate access revoked due to abuse - lest failure to adhere to useage policy is deemed worthy of isolation from total services. A combination of existing open source softwares, libre office/collabora, git, racktables(not concerned with "productivity" directly but can be abused for much - We will need an asset tracking system eventually anyway)

For ticketing software, Open Source solutions such as osTicket should be trivial to deploy and integrate into existing systems providing an easy to use location for tracking issues and resolutions across infrastructure, not just digital.

If we're really cunning, we can wrangle collaborational tools and a ticketing system into a single proposal

Tau 02, 01 / Mar 27, 17 18:13 UTC

Hi, as a person whose spent about 20+ years in PM / Scrum / Agile ... ITIL, ISO ... etc. I believe that we are on IDEAL point NOT to use MAJORITY of the "standards". Why?

From 1995 is visible how costly is to keep and drive a standards and that actually we didn't move too much in our quality, scalability, whatever, .. not even that we are doing things today even faster.

And reason is very simple - ,we are making our professional life very complicated but our products of today are NOT more efficient that ours grad fathers did.

Yes, today we are not able to make a battleship faster than it was 1942 - 1948 ... and this is reality! Why it is like that?

One of the reason is that we have too many "standards" and we kill all innovations during the production. If you have doubts - check how fast was built Mig21 and than latter all other Mig's in a 20+ years. And in last 20 years we have only several types of air-fighters whose .. actually can almost the same as Mig21.

This is the great moment to make step out of all "ISO standards", of all "Patents" etc. and to start be efficient again. We have to take our experience form existing world but we should NOT make any similar system for future Asgardian development.

Even, CT/IT should not be on the top of our interest but robotics. Not even AI as we are here to thing and to decide.

If you have any other doubt, than think about poor african countries whose has sometimes better mobile services than you can find in Central Europe. Why? As they don't care about old legacy, don't care on fix-network maintenance, don't care if you have fax service. They jump about 40 years of telecom development and they don't miss it. So, why we should start with inefficient standards whose NASA using (for example)?

If we are going to create "NASA 2.0" than we should rather stay a home.As NASA is also mostly @ home, not in a space. :)

BR, D :)

  Updated  on Tau 02, 01 / Mar 27, 17 18:17 UTC, edited 1 time in total.
Reason: tipos

Tau 03, 01 / Mar 28, 17 08:00 UTC

I'll agree that the proliferation of competing standards is a problem, but standards themselves are definitely a good thing.

Starting again is a good idea, but accounting for the future in a new system is less easy than it sounds. Failure to account for this results in the "suppression of innovation" by the standard itself.

Within the field of robotics, the mechanical articulation is of limited design possibilities. Most have been throughly explored. What remains to work on is the control software - the "computer" part of the robot, specifically the "AI" which is essential as humans cannot operate enough equipment, fast enough, reliably enough.

African countries with a better phone service than some european countries have achieved this by investing late into the technology, deploying "better" things "ealier" in their timeline - the weakest link in their chain is stronger than the weakest link in the many decades old chain only being used to scrape more profits out of something that's paid them back countless times in the first 12 months. They don't have this "legacy" hardware to fall back on and thusly started with the modern equipments, dropping down fibre before copper. If they'd invested in copper earlier, they'd possibly still be there now, assuming universal greed. They didn't try to hold on to 2G technology making it pay back even more, they deployed 3G to start with, 4G in some places. It's not about standards it's about "more money".

When it comes to standards, efficiency is just one face of this dodecahedron. Different purposes may lend different weights to different variables, like safety - which in most cases should prioritise above. The advantage of "standards" is being able to legitimately expect a, or a group of features. If attempting to build "new standards", first identify the desired features, this should then begin to sketch how to provide for them. Existing standards can save a lot of this workload, and ensure others are potentially complient.